id: Гость   вход   регистрация
текущее время 12:13 28/03/2024
Автор темы: vlcryptor, тема открыта 19/04/2010 08:40 Печать
Категории: криптография, протоколы
https://www.pgpru.com/Форум/Криптография/SSL-TLSЧерезWeb-браузер
создать
просмотр
ссылки

SSL-TLS через Web-браузер


Прочитал информацию по SSL-TLS и появилось несколько вопросов:


1) В обычном случае – без использования сертификата клиента, всегда ли будет шифроваться трафик от сервера к клиенту?


2) При работе SSL-TLS получается, что публичный ключ сервера отсылается при каждом новом соединении и нет возможности один раз установить публичный ключ в хранилище web-браузера у клиента и его использовать. Верно?


3) Каким образом происходит процедура проверки подписанного публичного ключа сервера центром сертификации(Verisign, Thawte)?
Ведь для того чтобы проверить ЭЦП ключа достаточно иметь публичный ключ центра сертификации, и он есть в хранилище сертификатов в браузере. Тогда получается незачем обращаться на сервер центра сертификации, но браузер обращается. Зачем?


 
На страницу: 1, 2 След.
Комментарии
— unknown (19/04/2010 09:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Детали реализации сложнее:
  1. Это зависит от настроек сервера. Если на странице например смешанный контент, то часть трафика пойдёт через hppts, а часть через http. Как сервер отдаёт страницы, так и будет. Всё зависит больше от него, а не от клиента. Если он захочет, то он наплюёт и на наличие клиентского сертификата и сделает в сеансе связи что-то неправильно.
  2. При каждом новом соединении происходит масса всяких сложных операций. Например генерируются одноразовые параметры Диффи-Хеллмана, из которых получается сеансовый симметричный ключ. Предусмотрены процедуры смены ключа через промежутки времени, используются функции KDF для получения множества подключей из одного, для аутентификации используются коды HMAC и т.д. Но главный ключ подписи, который аутентифицирует подлинность сервера и который устанавливает параметры шифрования и который пользователь воспринимает как "открытый ключ" — один. Он зашит в сертификат и его отпечаток постоянный. (за исключением использования множества сертификатов одним сервером параллельно).
  3. Каким образом происходит процедура проверки подписанного публичного ключа сервера центром сертификации(Verisign, Thawte)?
    Заказчик приносит УЦ открытую часть сертификата своего сервера. На него УЦ проставляет подпись от своего сертификата, заполнив в этом сертификате нужные поля (название домена и т.д.). Это технически. Как он проверяет личность заказчика — это формально-юридическая процедура.
    Ведь для того чтобы проверить ЭЦП ключа достаточно иметь публичный ключ центра сертификации, и он есть в хранилище сертификатов в браузере.
    Вторая часть вопроса не согласуется с первой или сформулированна двусмысленно.
    Тогда получается незачем обращаться на сервер центра сертификации, но браузер обращается. Зачем?
    А третья с двумя предыдущими. На основании чего сделан вывод? Браузер может никуда не обращаться кроме сервера, а действительно работать только со встроенным хранилищем сертификатов. Причины его коннекта с УЦ разные: проверка преждевременно отозванных сертификатов, попытка построения цепочки доверия на основе подписей до корневого УЦ при встрече с неизвестным сертификатом, возможно что-то ещё, здесь нет даже чётко прописанного стандарта.
— vlcryptor (19/04/2010 22:55, исправлен 19/04/2010 23:01)   профиль/связь   <#>
комментариев: 21   документов: 5   редакций: 5
Но главный ключ подписи, который аутентифицирует подлинность сервера и который устанавливает параметры шифрования и который пользователь воспринимает как "открытый ключ" — один. Он зашит в сертификат и его отпечаток постоянный. (за исключением использования множества сертификатов одним сервером параллельно).

Повторяю: есть ли в протоколе SSL-TLS возможность не передавать сертификат сервера(публичный ключ с подписью) каждый раз при новом соединении? Вот в чем был вопрос.


Каким образом происходит процедура проверки подписанного публичного ключа сервера центром сертификации(Verisign, Thawte)?

Заказчик приносит УЦ открытую часть сертификата своего сервера. На него УЦ проставляет подпись от своего сертификата, заполнив в этом сертификате нужные поля (название домена и т.д.). Это технически. Как он проверяет личность заказчика — это формально-юридическая процедура.



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


Вторая часть вопроса не согласуется с первой или сформулированна двусмысленно.

Это вы неправильно поняли 1 часть вопроса.


А третья с двумя предыдущими.

:)) В общем вы неправильно поняли 1 часть вопроса.


Браузер может никуда не обращаться кроме сервера, а действительно работать только со встроенным хранилищем сертификатов. Причины его коннекта с УЦ разные: проверка преждевременно отозванных сертификатов, попытка построения цепочки доверия на основе подписей до корневого УЦ при встрече с неизвестным сертификатом, возможно что-то ещё, здесь нет даже чётко прописанного стандарта.

Ну вот примерно так я и думал. Только обычно вся цепочка сертификатов центров сертификации тоже хранится в хранилище браузера.


А есть ли какие-либо RFC или документация по протоколу взаимодействия браузера с серверами центрами сертификации(Verisign, Thawte и т.д.)?

— SATtva (19/04/2010 23:03)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А есть ли какие-либо RFC или документация по протоколу взаимодействия браузера с серверами центрами сертификации(Verisign, Thawte и т.д.)?

Для онлайновой проверки действительности сертификатов (без CRL) используется протокол OCSP.
— vlcryptor (19/04/2010 23:39)   профиль/связь   <#>
комментариев: 21   документов: 5   редакций: 5
Для онлайновой проверки действительности сертификатов (без CRL) используется протокол OCSP.

Спасибо, буду разбираться.

Не знаете случайно почему я не могу отредактироать свой предыдущий пост? Была ссылка "Правка" а теперь ее нет.
— SATtva (19/04/2010 23:42)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Не знаете случайно почему я не могу отредактироать свой предыдущий пост?

Исправления возможны только пока не получен новый комментарий.
— Гость (20/04/2010 00:02)   <#>
[offtop]
... или пока не обнаружен новый 0day в движке, что уже пару раз тут случалось :)
P. S: на obsd.ru некогда стоял нормальный форумный движок, и всё было бы хорошо, но был он столь дыряв, что часто "случайно" позволял отредактировать произвольные сообщения модераторов. После очередного прикола с моей стороны терпение у них лопнуло, движок снесли и вместо него водрузили безопасную, но глючную и неудобную wiki. Наверное, зря я тогда так шутил над :)
[/offtop]
— SATtva (20/04/2010 00:06)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
или пока не обнаружен новый 0day в движке

Хехе. Этот пункт выведен из модели угрозы инструкции по эксплуатации как недокументированная возможность. :)
— Гость (20/04/2010 01:13)   <#>

А гостям бы тоже такую возможность!
— Гость (20/04/2010 03:12)   <#>
Да, на основе куков, например. Они всё равно [условно] безопасны, так как https.
— vlcryptor (20/04/2010 19:31, исправлен 20/04/2010 19:37)   профиль/связь   <#>
комментариев: 21   документов: 5   редакций: 5

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


Вообще избыточность, которую предлагают платные центры сертификации она отнюдь не более защищенная. SATtva, вот взять к примеру ваш сайт. У вас, например, сертификат подписан неизвестным ни одному моему браузеру cacert.org. Понятно, что при желании я могу установить его корневой сертификат. А как я его проверю? Он ведь тоже передается по сети. Где взять этот третий канал связи с неизвестным мне cacert.org?


Если используются такие известные центры сертификации как Verisign, Thawte и т.д., то их сертификаты уже есть в ОС(браузере). Но их защищенность от подмены тоже еще вопрос. Если взять к примеру такие браузеры как Firefox, Opera – их исходники подписаны с помощью корневых сертификатов, уже имеющихся в ОС. Т.е. это уже надо проверять дистрибутив ОС на отсутствие изменений. Лицензионное ПО в этом случае будет даже более защищенным, чем бесплатное, обычно загружаемое по сети.

— SATtva (20/04/2010 19:46)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
возможно ли один раз установить сертификат(публичный ключ сервера) в хранилище браузера, проверить его отпечаток по другим каналам один раз и чтобы браузер не загружал его каждый раз заново. Думаю это отсутствующие возможности SSL-TLS протокола.

С протоколом всё в порядке, это ограниченность реализации браузеров. Чтобы добиться того, о чём Вы спрашиваете, нужно удалить из хранилища все сертификаты УЦ. Когда браузер не может проверить подлинность сертификата через цепочку УЦ, вопрос установления доверия перекладывается на пользователя.

У вас, например, сертификат подписан неизвестным ни одному моему браузеру cacert.org. Понятно, что при желании я могу установить его корневой сертификат. А как я его проверю? Он ведь тоже передается по сети. Где взять этот третий канал связи с неизвестным мне cacert.org?

Не устанавливайте, никто не заставляет. Как раз в данном случае браузер должен предложить Вам сделать исключение для данного сертификата от "неизвестного" УЦ, после чего не будет задавать лишних вопросов. Только как Вы определите подлинность некоего произвольного самоподписанного или подписанного недоверенным УЦ сертификата? В нашем случае такой способ есть: при обновлениях сертификата в новостях сайта публикуется новый отпечаток, заверенный моим PGP-ключом.
— vlcryptor (20/04/2010 20:45)   профиль/связь   <#>
комментариев: 21   документов: 5   редакций: 5
С протоколом всё в порядке, это ограниченность реализации браузеров. Чтобы добиться того, о чём Вы спрашиваете, нужно удалить из хранилища все сертификаты УЦ. Когда браузер не может проверить подлинность сертификата через цепочку УЦ, вопрос установления доверия перекладывается на пользователя.

Не поняли вы меня. Об ограниченности реализации браузеров тоже думал. Но дело в другом, повторяю: сертификат вашего сайта вместе с публичным ключом передается мне каждый раз при каждом новом соединении, а необходимости в этом нет. Таков уж протокол SSL-TLS. :)
Если я удалю из хранилища браузера все сертификаты УЦ, чего я добьюсь? :)


В нашем случае такой способ есть: при обновлениях сертификата в новостях сайта публикуется новый отпечаток, заверенный моим PGP-ключом.

Так, а как мне проверить достоверность этого нового отпечатка, передаваемого также через Интернет?
Или как мне проверить достоверность вашего PGP-ключа, который я также могу получить только через Интернет? :)
— sentaus (20/04/2010 21:32)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Но дело в другом, повторяю: сертификат вашего сайта вместе с публичным ключом передается мне каждый раз при каждом новом соединении, а необходимости в этом нет.

И что? Если браузер его "помнит", то никаких предупреждений уже не будет – сайту ж в любом случае как-то надо сказать клиенту "я использую сертификат X".

Лицензионное ПО в этом случае будет даже более защищенным, чем бесплатное, обычно загружаемое по сети.


Вопрос лицензионности здесь ни при чём – видимо, имеется ввиду поставка софта на "твёрдых" носителях на прямую от производителя к потребителю без посредников?
— vlcryptor (20/04/2010 21:42)   профиль/связь   <#>
комментариев: 21   документов: 5   редакций: 5
сайту ж в любом случае как-то надо сказать клиенту "я использую сертификат X".

Для этого достаточно связать данный сетрификат с сайтом – все. А если сервер решит сменить публичный ключ(сертификат), то он может сообщить об этом браузеру в диалоге рукопожатий(аутентификации) после того сервер убедился, что у клиента есть его публичный ключ.

видимо, имеется ввиду поставка софта на "твёрдых" носителях на прямую от производителя к потребителю без посредников?

Именно коробочные версии продуктов я и подразумеваю.

Вопрос лицензионности здесь ни при чём

А вы часто покупаете ОС с открытыми исходниками(Linux, BSD) в коробке? :)
Даже если конкретно вы это делаете, подавляющее большинстов пользователей все равно загружает из Интернета.
— sentaus (20/04/2010 21:51, исправлен 20/04/2010 21:51)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Именно коробочные версии продуктов я и подразумеваю.

Тогда всё упирается в порядочность производителя в случае прямых продаж (которых в природе почти нет) и в сложность подделки коробки, диска и прочих бумажек при продаже через посредников :)

На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3