Обсуждение:SSL

message: в Обсуждении:TLS
thread_title:  Объединение TLS и SSL 

message: Ничего не написано об уязвимости в SSL renegotiation, программа для которой THC-SSL-DOS написана ещё во второй половине 2011, значимое же и до сих пор рабочее или я что-то путаю? http://www.securitylab.ru/news/409039.php
thread_title:  Повторное подтверждение SSL 

message: Общепринятое сокращение для атаки Man-in-the-middle - "MITM" см. [], а не "MIM", используемое в данной статье ("MIM" тоже употребляется, т.е. это допустимый синоним, но здесь лучше общепринятый термин). Arcadius 12:43, 12 ноября 2010 (UTC)
replies: text: MitM (предлоги и артикли пишутся с маленькой буквы). Поправил.
Удалил последнюю ссылку, явное seo, ресурс украинский, часть текста на украинском, о чем не указано в ссылке, рекламирует какой-то украинский центр сертификации. 178.216.72.22 00:02, 13 января 2011 (UTC)
thread_title:  MIM vs MITM 

message: * От теории к практике: взлом SSL 
* На Black Hat показали еще один взлом SSL 
* поиск: SSL+взлом
thread_title:  См. также 

message: Layer переводится как "слой" а не "уровень", если я не ошибаюсь Zenkor 12:40, 3 мая 2012 (UTC)
в данном контексте это синонимы и нет разницы, какой использовать. имхо.  msangel 23:48, 14 июля 2012 (UTC)
thread_title:  Аббревиатура 

message: Здравствуйте. Прочитав вот это:
«Во-вторых, с помощью закрытого ключа сторона-обладатель закрытого ключа может создавать зашифрованные сообщения, которые может прочесть кто угодно (ведь для расшифровки нужен открытый ключ, доступный всем), но при этом прочитавший может быть уверен, что это сообщение было создано стороной-обладателем секретного ключа.»
Можно сделать вывод о том, что SSL не гарантирует конфиденциальность отправляемых данных клиенту. Неужели, сервер не шифрует данные открытым ключом клиента, а использует для этого свой приватный, чтобы кто угодно мог получить доступ к ним?
--92.37.179.207 08:02, 4 января 2013 (UTC)
thread_title:  Второй абзац статьи 

message: Используя все данные, полученные до сих пор от процедуры рукопожатие, клиент (в сотрудничестве с сервером) создает предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера , отправленного на 2-ом шаге), а затем отправляет зашифрованный его на сервере.
Автор сообщения:  195.19.50.64 14:22, 21 апреля 2013 (UTC)
replies: text: . Sealle 04:25, 27 апреля 2013 (UTC)
thread_title:  Сообщение об ошибке 

message: Добавил информацию по уязвимости CVE-2014-3566
Ссылку на уязвимость добавить мне не дает, думаю, имеет смысл вставить http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566
Также:
# немного подправил иерархичность раздела Безопасность
# добавил информацию по осуществлению MITM-атаки в организациях с помощью Blue Coat Proxy SG
 Alfut 08:56, 12 ноября 2014 (UTC)
thread_title:  Уязвимость CVE-2014-3566 

message: 1. SSLstrip - это не атака на SSL, это атака на браузер/пользователя для обхода ssl вообще. 
Утилита работает потому, что многие сайты использующие защиту SSL имеют незащищенную главную страницу. Они шифруют только те разделы, где передается важная информация. И когда пользователь кликает по странице авторизации утилита подменяет ответ сайта меняя https на http. 
Утилита будет работать даже если сайт отдает страницы только по https - она расшифровывает страницу и отдает ее клиенту по http. Единственная защита от этого - чтобы пользователи обращали внимание на то, чтобы они заходили на сайты по https.
"... --- криптографический протокол, который подразумевает более безопасную связь." Более безопасную, чем что? Какую связь? 37.112.185.6 13:53, 15 ноября 2016 (UTC)
thread_title:  SSLstrip 

message: Хотелось бы видеть раздел с проблемами при использовании TLS по сравнению с неиспользованием. Например: при смены доменного имени необходимо пересоздавать сертификат.
thread_title:  Недостатки