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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Объединение TLS и SSL[править код]

в Обсуждении:TLS — Эта реплика добавлена участником Grain (ов) 02:24, 10 декабря 2006 (UTC)[ответить]

Повторное подтверждение SSL[править код]

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

Общепринятое сокращение для атаки Man-in-the-middle - "MITM" см. [[1]], а не "MIM", используемое в данной статье ("MIM" тоже употребляется, т.е. это допустимый синоним, но здесь лучше общепринятый термин). Arcadius 12:43, 12 ноября 2010 (UTC)[ответить]

MitM (предлоги и артикли пишутся с маленькой буквы). Поправил.

Удалил последнюю ссылку, явное seo, ресурс украинский, часть текста на украинском, о чем не указано в ссылке, рекламирует какой-то украинский центр сертификации. 178.216.72.22 00:02, 13 января 2011 (UTC)[ответить]

См. также[править код]

— Эта реплика добавлена с IP 178.150.101.122 (о) 17:54, 27 мая 2011 (UTC)[ответить]

Аббревиатура[править код]

Layer переводится как "слой" а не "уровень", если я не ошибаюсь Zenkor 12:40, 3 мая 2012 (UTC)[ответить]

в данном контексте это синонимы и нет разницы, какой использовать. имхо. msangel 23:48, 14 июля 2012 (UTC)[ответить]

Второй абзац статьи[править код]

Здравствуйте. Прочитав вот это:

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

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

Сообщение об ошибке[править код]

Перенесено со страницы ВП:Сообщения об ошибках#SSL.

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

Автор сообщения: 195.19.50.64 14:22, 21 апреля 2013 (UTC)[ответить]

К обсуждению. Sealle 04:25, 27 апреля 2013 (UTC)[ответить]


Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Рецензирование статьи SSL[править код]

Дополнил и внес изменения, частично переработал статью. Интересует, все ли корректно написано с криптографической точки зрения. Подскажите, пожалуйста. jonics 14:33, 21 мая 2013 (UTC)[ответить]

  • Статью надо перерабатывать дальше. При наличии нескольких книг и длительной истории протокола практически ни один пункт не раскрыт толком. Указать источники. Ряд источников требованиям ВП:АИ не удовлетворяет (например, №31). Филатов Алексей 12:31, 21 мая 2013 (UTC)[ответить]
  • «криптографический протокол, который обеспечивает безопасность связи через Интернет [1]» — ссылка ведёт на спецификацию TLS. Кроме того, а почему только Интернет?
  • «Несколько версий протоколов широко используются» — то ли сразу несколько версий используются, то ли разные версии используются. Кроме того, веб-браузер это программа, она без веб-сервера не может использоваться. Кстати, я об этом уже указывал в личной рецензии.
  • «запись не имеет заполнителя» — под заполнителем понимается термин «padding» двумя строчками ниже?
  • «Причем, содержимое заполнителя никакой роли не играет» — ё-фикация, пунктуация.
  • «содержала много недостатков по безопасности, которые привели к разработке SSL версии 3.0» — а чья это цитата, чтобы забирать её в кавычки?
  • «работающие с интернет-деньгами» — неизвестный термин
  • «имеют лицензию» — до какого срока это требует лицензии?
  • «SSL работает модульным способом» — почему этот факт находится в описании истории, а не в описании структуры протокола?
  • «качестве обновления версии SSL 3.0 Как указано» — пунктуация.
  • «включает средства, с помощью которых реализация подключения TLS к SSL 3.0, ослабит безопасность» — пунктуация.

Дальше сами. — Vlsergey 12:51, 21 мая 2013 (UTC)[ответить]

  • Внес исправления по вышеуказанным моментам, пересмотрел внимательно и исправил еще ряд косяков. Vlsergey, «имеют лицензию» — до какого срока это требует лицензии?. Не понял, что стоит указать? В статье изменил немного формулировку. jonics 16:31, 24 мая 2013 (UTC)[ответить]
  • Под лицензированием алгоритмов обычно понимается разрешение на использование в соответствии с патентом. SSL запатентован? Если да, то до какого срока патент действителен? Если нет, то на что тогда выдаётся лицензия? На использование программного обеспечения? Но львиная его доля распространяется под open source. Или это государственная лицензия на право использования и реэкспорта? -- Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • Сноска 38 ведён на русский перевод RFC. Почему не на официальный английский вариант? — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • «Обработка ошибок в протоколе SSL» — каким образом устраняются те или иные ошибки? — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • «Также SSL получил широкое применение в электронной почте» — что имеется ввиду? — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • «Пакет предназначен для создания и управления различного рода сертификатами» — а из строчки выше получается, что в первую очередь — для SSL. — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • «Протокол записи», «Аутентификация и обмен ключами» — ни одного источника в разделах — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • «Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу» — ровно наоборот. Кроме того, приемлемому с чьей точки зрения? — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • «Для того чтобы предотвратить остановку секрета» — предотвратить что? — Vlsergey 12:56, 24 мая 2013 (UTC)[ответить]
  • Как я понял, Вам эти источники не нравятся, потому я решил их убрать. Прошу проверить очередную вресию статьи. jonics 18:02, 29 мая 2013 (UTC)[ответить]
  • Мне эти источники показались неревалентными для данной темы, и они уж точно не подтверждали то, что написано в статье. Не нужно вставлять "ссылки по теме" в качестве сносок. Сносками должны служить авторитетные источники, которые использовались для написания конкретного места в статьи. И да, статья должна быть написана только по авторитетным источникам. -- Vlsergey 14:22, 29 мая 2013 (UTC)[ответить]

Уязвимость CVE-2014-3566[править код]

Добавил информацию по уязвимости CVE-2014-3566 Ссылку на уязвимость добавить мне не дает, думаю, имеет смысл вставить http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 Также:

  1. немного подправил иерархичность раздела Безопасность
  2. добавил информацию по осуществлению MITM-атаки в организациях с помощью Blue Coat Proxy SG
Alfut 08:56, 12 ноября 2014 (UTC)[ответить]

1. SSLstrip - это не атака на SSL, это атака на браузер/пользователя для обхода ssl вообще.

Утилита работает потому, что многие сайты использующие защиту SSL имеют незащищенную главную страницу. Они шифруют только те разделы, где передается важная информация. И когда пользователь кликает по странице авторизации утилита подменяет ответ сайта меняя https на http.

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

"... --- криптографический протокол, который подразумевает более безопасную связь." Более безопасную, чем что? Какую связь? 37.112.185.6 13:53, 15 ноября 2016 (UTC)[ответить]

Недостатки[править код]

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