Почему победил HTTPS? Кто-нибудь знает какие-либо конкретные причины, по которым Netscape и Microsoft выбирают HTTPS вместо того S-HTTP (RFC 2660)?
Мне кажется, что S-HTTP более гибкий и не требует отдельного IP или порта для обслуживания правильного сертификата, потому что S-HTTP может использовать заголовок Host. Было ли в то время проблемой IP-пространство?
Я вижу аргумент, что HTTPS зашифровал больше данных подключения, чем S-HTTP, но я не вижу особого смысла, если вы можете так же легко определить, к какому веб-сайту обратился пользователь, потому что существует только один сайт на IP (большая часть время), а сертификат обычно говорит, какой домен в любом случае.
Мой ответ: SSL, созданный в 1993/1994 Netscape, и HTTPS, естественно, был добавлен к нему примерно в то же время в 1994 году. Первоначальная цель HTTPS заключалась в модернизации существующих протоколов для обеспечения безопасности без каких-либо изменений. S-HTTP не появлялся до 1999 года и требовал HTTP 1.1, поэтому к тому времени HTTPS был настолько широко распространен, что от внедрения S-HTTP было мало пользы. Спасибо всем.
РЕДАКТИРОВАТЬ: Я видел RFC 2817 под названием "S-HTTP" в нескольких местах, но это неверно и не имеет ничего общего с вопросом о RFC 2660, поскольку @ Дэйв Холланд указал в своем ответе. Некоторые элементы моего ответа также могут относиться к RFC 2660, и это может быть полезно для сравнения, так как есть сходства, но я действительно не заслуживаю голосования здесь. Приносим извинения за путаницу ...
Я думаю, что общие упреки в адрес S-HTTP HTTP, обновленный до TLS по сравнению с HTTPS, заключается в том, что можно было бы выполнить атаку перехода на более раннюю версию, перехватывая, но не передавая Upgrade сообщение (хотя сервер может что-то с этим сделать) и что с точки зрения браузера сложнее определить, предназначен ли URI для защиты или нет (https:// vs. http:// префикс). (Это, конечно, совершенно противоположные аргументы, используемые протоколами, которые используют такие механизмы, как STARTTLS, гораздо больше похоже на S-HTTP HTTP обновлен до TLS.) В обоих случаях протоколы должны быть правильно настроены (правильные наборы шифров, ...), а пользовательский интерфейс должен предоставлять пользователю достаточно информации, чтобы судить, является ли соединение безопасным или нет (хороший сертификат / плохой сертификат, ...).
Что еще более важно, это, вероятно, связано с "рыночными силами", которые исторически реализовывали HTTPS, но не S-HTTP, и не видели причин для изменений (на базовом уровне SSL / TLS этого было достаточно, чтобы перейти от SSLv2 к SSLv3 и TLSv1 и выше).
К тому же, RFC 2817 был опубликован в 2000 году, и к тому времени HTTPS уже существовал некоторое время. В Upgrade Механизм также полагается на использование HTTP 1.1, тогда как HTTPS можно заставить работать и через HTTP 1.0 (и в то время не все поддерживало HTTP 1.1).
Вы можете найти эти темы, представляющие интерес:
SHTTP был изобретен и реализован в Mosaic и NCSA httpd в 1993 году. HTTPS победил на рынке, потому что Mosaic Communications Corporation / Netscape разработали и встроили SSL в Netscape Navigator и Netscape Enterprise Server. Netscape отказался от реализации SHTTP. После выпуска Netscape никто не хотел использовать Mosaic.
Некоторые комментарии / треды от фактических лиц, принимающих решения в то время, были бы интересны - я могу сказать, что в то время я не помню, чтобы много слышал о s-http, а https был там раньше.
Оглядываясь назад, можно сказать, что спецификация s-http выглядит очень открытой и гибкой, что, возможно, и убило ее - https, как я полагаю, указывает на использование SSL и подразумевает использование глобальной PKI и то, как это будет работать - где s-http сказал «Да, мы можем это сделать, если хочешь ... плюс все это».
Я могу вам сказать, что S-HTTP шифрует отдельные сообщения, а HTTPS шифрует весь канал связи, это может быть частью причины с технической точки зрения. Из-за того, что он шифрует только отдельные сообщения, его нельзя использовать в качестве протокола для таких вещей, как VPN. Я действительно не утверждаю, что знаю иное. Видеть http://tools.ietf.org/html/rfc2660 для получения дополнительной информации о S-HTTP.