[image]

HTTPS и параметры GET-запросов

Будут ли зашифрованы параметры GET-запросов при использовании HTTPS?
 
+
-
edit
 

anybody

координатор

админ. бан
Добрый день!

Пока копался в описаниях разных систем, возник у меня следующий вопрос.

Сайт использует HTTPS, сертификат правильный, подписан хорошим центром, VeriSign, например. Верно ли утверждение: параметры GET-запросов путешествуют по сети в зашифрованном виде.

Как я понимаю, верно даже более жёсткое утверждение: запрашиваемые адреса путешествуют по сети в зашифрованном виде. А всё поскольку HTTPS шифруется на Transport Layer-е, а HTTP-протокол является порождением Application Layer-а.

Кто что думает? Причина вопроса понятна: хочется придумать простую и защищённую от прыщавых псевдохакеров штуку. :)
   
RU bjaka_max #04.10.2011 22:28  @anybody#04.10.2011 22:09
+
-
edit
 

bjaka_max

втянувшийся

anybody> Сайт использует HTTPS, сертификат правильный, подписан хорошим центром, VeriSign, например. Верно ли утверждение: параметры GET-запросов путешествуют по сети в зашифрованном виде.
Да, в QT, например, работа с HTTPS проходит через SecureSocket, тоесть весь трафик от\к серверу шифруется, и HTTP заголовки соответственно тоже.
anybody> Как я понимаю, верно даже более жёсткое утверждение: запрашиваемые адреса путешествуют по сети в зашифрованном виде.
Нет, адрес запрашивается у DNS сервера, а DNSSEC пока ещё не слишком распространён, в зоне ru он кажется вообще не работает.
   1212
RU anybody #04.10.2011 22:37  @bjaka_max#04.10.2011 22:28
+
-
edit
 

anybody

координатор

админ. бан
bjaka_max> Нет, адрес запрашивается у DNS сервера, а DNSSEC пока ещё не слишком распространён, в зоне ru он кажется вообще не работает.

У DNS-сервера запрашивается IP, соответствующий доменному имени (подробности опустим). Это допустимо в подавляющем большинстве случаев. А дальше всё путешествует в шифрованном виде, как я понимаю.
   7.0.17.0.1
IL TheFreeMan #04.10.2011 22:44  @anybody#04.10.2011 22:37
+
-
edit
 

TheFreeMan

втянувшийся

anybody> ... А дальше всё путешествует в шифрованном виде, как я понимаю.

Ага, HTTPs это HTTP over SSL(TLS), а SSL - транспорт (секьюрный).
   14.0.835.18714.0.835.187
RU bjaka_max #04.10.2011 23:08  @anybody#04.10.2011 22:37
+
-
edit
 

bjaka_max

втянувшийся

anybody> У DNS-сервера запрашивается IP, соответствующий доменному имени (подробности опустим). Это допустимо в подавляющем большинстве случаев. А дальше всё путешествует в шифрованном виде, как я понимаю.

Да. Тут правда недавно продемонстрировали успешную атаку на SSL. Нужно перехватывать пакеты жертвы и запустить в её браузере (например в iframe или в соседней вкладке) javascript. скрипт начинает соединение с тем же сервером, и пытается подобрать начало запроса таким образом, что-бы зашифрованные пакеты совпали. А поскольку в браузерах обращения к одному серверу заворачиваются в одну SSL сессию, то при совпадении зашифрованных пакетов и расшифрованные данные совпадут. Таким образом можно, например получить куки пользователя. На нормальном канале время подбора десятки минут.
   1212
+
-
edit
 

Mishka

модератор
★★★
anybody> Сайт использует HTTPS, сертификат правильный, подписан хорошим центром, VeriSign, например. Верно ли утверждение: параметры GET-запросов путешествуют по сети в зашифрованном виде.
У тебя два выбора на данный момент — или SSL (Socket Secure Layer — Netscape protocol), или TLS (Transport Layer Security — IETF protocol). Это примерно одно и тоже, просто IETF не хочет судебных преследований и у неё политика не принимать частные протоколы в качестве стандартов. Оба протакола лежат между TCP слоем и программкой. Поэтому весь трафик шифруется ещё до попадания в сокет.

anybody> Как я понимаю, верно даже более жёсткое утверждение: запрашиваемые адреса путешествуют по сети в зашифрованном виде. А всё поскольку HTTPS шифруется на Transport Layer-е, а HTTP-протокол является порождением Application Layer-а.

Если ты имеешь ввиду IP адреса, то нет, они не шифруются. Шифруется payload TCP. Шифрация IP адресов не возможна, т.к. надо маршрутить пакет. Т.е. либо раутер должен иметь ключ на расшифровку, либо поле незашифрованное.

Если у тебя есть возможность организовать VPN штатными средствами линя/фряхи, то там шифруется и TCP поля, и защищаются часть заоголовка IP. Т.е. адреса не шифруются, но адреса серверов, между которыми VPN (или клиента/сервера) — как там идёт дальше маршрутизация снаружи не видно. Но возни больше.

PS С TLS с точки зрения полной поддержки сертификатов тоже возни хватает.
   6.06.0
+
-
edit
 

Mishka

модератор
★★★
bjaka_max> Нет, адрес запрашивается у DNS сервера, а DNSSEC пока ещё не слишком распространён, в зоне ru он кажется вообще не работает.
Э, а причём тут DNSSec? Там защищается само общение с DNS, но не IP адреса.

DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data.
   6.06.0
+
-
edit
 

Mishka

модератор
★★★
anybody> У DNS-сервера запрашивается IP, соответствующий доменному имени (подробности опустим). Это допустимо в подавляющем большинстве случаев.

Да.

anybody> А дальше всё путешествует в шифрованном виде, как я понимаю.

Нет. Только payload of a TCP packet.
   6.06.0
+
-
edit
 

Mishka

модератор
★★★
bjaka_max> На нормальном канале время подбора десятки минут.

Чего-то меня берут сомнения. :) Там открытый ключ используется только для начальной торговли. Потом генерится симметричный временный ключ офигенной длины. Он работает какое-то время, а потом обновляется в соответствии с договорённостью при начальной торговле.
   6.06.0
+
-
edit
 

bjaka_max

втянувшийся

bjaka_max>> Нет, адрес запрашивается у DNS сервера, а DNSSEC пока ещё не слишком распространён, в зоне ru он кажется вообще не работает.
Mishka> Э, а причём тут DNSSec? Там защищается само общение с DNS, но не IP адреса.
Mishka> DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data.

Ну собственно ip адрес по понятным причинам зашифровать нельзя, там только возможны разные игры с проксированием и туннелированием, но не более того, поэтому я вообще о таком не подумал. DNSSec зашифрует доменное имя необходимое пользователю.
   1212
+
-
edit
 

bjaka_max

втянувшийся

Mishka> Чего-то меня берут сомнения. :) Там открытый ключ используется только для начальной торговли. Потом генерится симметричный временный ключ офигенной длины. Он работает какое-то время, а потом обновляется в соответствии с договорённостью при начальной торговле.

Ключ не надо взламывать, надо подобрать http заголовок, а он небольшой. И большая часть будет заранее известна, поскольку браузер тот же самый. В принципе можно эту атаку парировать с сервера достаточно просто, если например Etag подавать постоянно случайный, браузер будет вынужден отвечать тем-же тегом и заголовок постоянно меняться будет.
   1212
+
-
edit
 

Mishka

модератор
★★★
bjaka_max> DNSSec зашифрует доменное имя необходимое пользователю.

DNSSEC зашфрует сессию общения с ним. :) Поэтому нельзя будет сделать инжекшен неправильной записи (обычно A типа) на запрос.
   6.06.0
+
-
edit
 

Mishka

модератор
★★★
bjaka_max> Ключ не надо взламывать, надо подобрать http заголовок, а он небольшой. И большая часть будет заранее известна, поскольку браузер тот же самый. В принципе можно эту атаку парировать с сервера достаточно просто, если например Etag подавать постоянно случайный, браузер будет вынужден отвечать тем-же тегом и заголовок постоянно меняться будет.

Блин, для симметричного ключа это почти взом. :) Ну и обмен там идёт буферами, а не совсем потоком. А буфер, ИМХО, дополняется не совсем тривиально. Ну и доступ к шифрованному надо иметь — иначе как сравнивать?

А так решений море. Можно токены выдавать и протокол на базе XML есть (Standards | OASIS ищи SAML). Мы в банке делали. Правда, возьни много.
   6.06.0
+
-
edit
 

bjaka_max

втянувшийся

Mishka> Блин, для симметричного ключа это почти взом. :) Ну и обмен там идёт буферами, а не совсем потоком. А буфер, ИМХО, дополняется не совсем тривиально. Ну и доступ к шифрованному надо иметь — иначе как сравнивать?
Буфер наоборот ситуацию усугубляет. Если мой склероз мне изменяет то он в SSL как правило 64 байта. И достаточно один буфер подобрать, в котором кука лежит. Нам собственно только куку подбирать и надо, остальная часть заголовка не меняется. А доступ, да, к трафику нужен. Но если доступ злоумышленник получить не может, то нафига вообще шифрование?
   1212
+
-
edit
 

anybody

координатор

админ. бан
Mishka> Если ты имеешь ввиду IP адреса, то нет, они не шифруются. Шифруется payload TCP. Шифрация IP адресов не возможна, т.к. надо маршрутить пакет. Т.е. либо раутер должен иметь ключ на расшифровку, либо поле незашифрованное.

Нет, я имел в виду URI целиком, то, что кто-то будет знать, что клиент обращается к моему серверу--- фиг с ним. :) Тут, пока, нужно сделать защиту от прыщавого псевдохакера, чтобы он не мог узнать пути (/this/is/path) и GET-параметры запросов. Сессии короткие, десятков минут у злоумышленника не будет.

Mishka> Если у тебя есть возможность организовать VPN штатными средствами линя/фряхи

Нет такой возможности. :)

Mishka> PS С TLS с точки зрения полной поддержки сертификатов тоже возни хватает.

Придётся работать... Какая жалость! :)
   
+
-
edit
 

Mishka

модератор
★★★
bjaka_max> Буфер наоборот ситуацию усугубляет.

Ты имеешь доступ до буфера? И как тебе это поможет, если и кука шифрованая, и дополнение подобрано до шифрования нужным образом (не одним и тем же), а потом зашифровано?

bjaka_max> Если мой склероз мне изменяет то он в SSL как правило 64 байта. И достаточно один буфер подобрать, в котором кука лежит.

А чем тебе кука поможет? Это, если кука статическая и никогда не меняется.

bjaka_max> Нам собственно только куку подбирать и надо, остальная часть заголовка не меняется. А доступ, да, к трафику нужен. Но если доступ злоумышленник получить не может, то нафига вообще шифрование?

Блин, как ты со скрипта получаешь доступ к буферу? Как ты в буфере знаешь где начало и конец заголовка?
   6.06.0
+
-
edit
 

Mishka

модератор
★★★
anybody> Нет, я имел в виду URI целиком, то, что кто-то будет знать, что клиент обращается к моему серверу--- фиг с ним. :) Тут, пока, нужно сделать защиту от прыщавого псевдохакера, чтобы он не мог узнать пути (/this/is/path) и GET-параметры запросов. Сессии короткие, десятков минут у злоумышленника не будет.

Ты же обращаешься к серверу. IP адрес известен, серверное DNS имя известно, если есть перехват DNS трафика и возможности связать этот перехват с последующим соединением. Первая часть URL — это серверное имя, вторая — путь. Путь параметр GET. Весь HTTP трафик зашифрован.
   6.06.0
+
-
edit
 

bjaka_max

втянувшийся

Mishka> Ты имеешь доступ до буфера? И как тебе это поможет, если и кука шифрованая, и дополнение подобрано до шифрования нужным образом (не одним и тем же), а потом зашифровано?
Я ж там написал, "нужно перехватывать пакеты жертвы", тоесть злоумышленник сидит на роутере по которому идёт трафик жертвы. И он каким-то образом обеспечил запуск в браузере жертвы скрипта. Да атака сложна. Но и разговор то идёт о протоколе который по логике должен обеспечивать безопасность в том числе и банковских транзакций.
Mishka> А чем тебе кука поможет? Это, если кука статическая и никогда не меняется.
Если жертва залогинена на сайте банка, то кука поможет зайти в эту-же сессию и выполнить действия от имени жертвы, например.
Mishka> Блин, как ты со скрипта получаешь доступ к буферу?
Со скрипта не надо получать.
Mishka> Как ты в буфере знаешь где начало и конец заголовка?
Я подробностей если честно не знаю, по понятным причинам сорцы эксплоита они не выкладывали, но говорят, что атака успешна.
   1212
+
-
edit
 

anybody

координатор

админ. бан
Mishka> Ты же обращаешься к серверу. IP адрес известен, серверное DNS имя известно, если есть перехват DNS трафика и возможности связать этот перехват с последующим соединением. Первая часть URL — это серверное имя, вторая — путь. Путь параметр GET. Весь HTTP трафик зашифрован.

Извиняюсь. Ошибку допустил. Нужно защитить не всю URI, а только путь и GET-параметры, вторую часть URI. Из твоего высказывания я понял, что эта часть путешествует по сети в зашифрованном виде. Я прав?

Имя сервера я и сам этому хакеру назову. :)
   
RU anybody #06.10.2011 11:43  @bjaka_max#06.10.2011 07:34
+
-
edit
 

anybody

координатор

админ. бан
bjaka_max>...и разговор то идёт о протоколе который по логике должен обеспечивать безопасность в том числе и банковских транзакций.

Обеспечивать безопасность операций уровня банковских транзакций, проводимых на полностью контролируемом злоумышленником компьютере... Хм... Однако! :)

"В наше время контрразведчик не может доверять никому, порой даже самому себе. Мне, правда, верить можно". Старина Мюллер об этой задаче. :)
   
RU bjaka_max #06.10.2011 13:47  @anybody#06.10.2011 11:43
+
+1
-
edit
 

bjaka_max

втянувшийся

bjaka_max>>...и разговор то идёт о протоколе который по логике должен обеспечивать безопасность в том числе и банковских транзакций.
anybody> Обеспечивать безопасность операций уровня банковских транзакций, проводимых на полностью контролируемом злоумышленником компьютере... Хм... Однако! :)
anybody> "В наше время контрразведчик не может доверять никому, порой даже самому себе. Мне, правда, верить можно". Старина Мюллер об этой задаче. :)
Почему контроллируемом то? Тогда вообще любой компьютер с которого открыта страница в инете потенциально "контроллируемый злоумышленниками". Вот вы сейчас страничку форума читаете, а значит скрипты у вас (с форума) запустились. Вы можете гарантировать что на роутере вашего провайдера не сидит злоумышленник? А если он там есть, то он может подмешать в страницу которую вы сейчас читаете скрипт, и потихоньку ломать вашу сессию на сервере банка, которая открыта на соседней вкладке браузера со страницей сайта банка, и которая вроде-бы надёжно защищена SSL.
   1212
RU bjaka_max #06.10.2011 13:50  @anybody#06.10.2011 11:37
+
-
edit
 

bjaka_max

втянувшийся

anybody> Из твоего высказывания я понял, что эта часть путешествует по сети в зашифрованном виде. Я прав?
Да. В зашифрованном.
   1212

Последние действия над темой

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru