Робинзон с ноутбуком.

Представьте себе, что вы попали на необитаемый остров подобно героям жюльверновского Таинственного Острова. У вас есть с собой ноутбук, на котором вполне могут быть какие-то астрономические программы, ну скажем, xephem, celestia и stellarium. Можно даже с исходниками.

И есть, допустим, секстан.

Одна беда, батарейка CMOS в этом ноутбуке накрылась, и показывает он время 1-го января 1970 года.

Задача - определить свои координаты - широту и долготу. Встроенного радиоприемника и GPS в ноутбуке нет, возможно есть wifi и bluetooth, но толку-то с них на необитаемом острове.
Интересно, какой процент моих читателей справится с задачей прежде чем аккумулятор в ноутбуке сядет?

Чем ближе криптография к прикладному уровню, тем целее ваши данные

Весь интернет буквально бурлит в TLS найдена уязвимость на уровне протокола.

Что же это собственно, за уязвимость? (подробности на английском)
)
Некто, кто ухитрился вклиниться между легитимным клиентом и сервером может перехватив исходный пакет TLS хэндшейка, его задержать, а вместо этого сам установить TLS-соединение с сервером,
передать туда какие-то данные, а потом пропустить исходный пакет, зашифровав его ключами своего соединения. Сервер воспримет это как совершенно легитимный повторный хэндшейк. Договорится уже с клиентом (атакующий должен все дальнейшие пакеты передавать между клиентом и сервером as is).

В процессе нового хэндшейка сервер может потребовать у клиента сертификат и аутентифицировать его.

Вот после этого и начинается засада.

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

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

Плюс еще особенности HTTP/1.x, позволяющие насовать в запрос сколько угодно непонятных серверу заголовков, которые тот должен проигнорировать.

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

Кстати, не обязательно чтобы авторизация требовала сертификата. Basic-Auth сработает точно так же (при условии что атакующему не надо подменять тело запроса, а только первую строчку.


Увидеть результаты запроса атакующий не сможет. Потому что сервер их отдаст зашифрованные теми ключами, которые клиент с ним согласовал при повторном хэндшейке.

Но вот если запрос содержит URL, по которой сервер может изменить какие-то данные, то это может и получиться.

Отсюда мораль:

1. Никогда не делайте на TLS-сайтах форм для изменения данных, передаваемых методом GET.
2. Никогда не делайте на TLS-сайтах такого web-приложения, в котором разные URL с одним и тем же набором POST-параметров могут привести к разным действиям.
3. Обращайте внимание на нестандартные заголовки в запросе. Может иногда стоит отдать клиенту лишний раз 400.

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

Чем ближе криптография к прикладному уровню, тем целее ваши данные

Весь интернет буквально бурлит в TLS найдена уязвимость на уровне протокола.

Что же это собственно, за уязвимость? (подробности на английском)
)
Некто, кто ухитрился вклиниться между легитимным клиентом и сервером может перехватив исходный пакет TLS хэндшейка, его задержать, а вместо этого сам установить TLS-соединение с сервером,
передать туда какие-то данные, а потом пропустить исходный пакет, зашифровав его ключами своего соединения. Сервер воспримет это как совершенно легитимный повторный хэндшейк. Договорится уже с клиентом (атакующий должен все дальнейшие пакеты передавать между клиентом и сервером as is).

В процессе нового хэндшейка сервер может потребовать у клиента сертификат и аутентифицировать его.

Вот после этого и начинается засада.

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

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

Плюс еще особенности HTTP/1.x, позволяющие насовать в запрос сколько угодно непонятных серверу заголовков, которые тот должен проигнорировать.

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

Кстати, не обязательно чтобы авторизация требовала сертификата. Basic-Auth сработает точно так же (при условии что атакующему не надо подменять тело запроса, а только первую строчку.


Увидеть результаты запроса атакующий не сможет. Потому что сервер их отдаст зашифрованные теми ключами, которые клиент с ним согласовал при повторном хэндшейке.

Но вот если запрос содержит URL, по которой сервер может изменить какие-то данные, то это может и получиться.

Отсюда мораль:

1. Никогда не делайте на TLS-сайтах форм для изменения данных, передаваемых методом GET.
2. Никогда не делайте на TLS-сайтах такого web-приложения, в котором разные URL с одним и тем же набором POST-параметров могут привести к разным действиям.
3. Обращайте внимание на нестандартные заголовки в запросе. Может иногда стоит отдать клиенту лишний раз 400.

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