> Проблема существует с 2001 года, когда выпустили IE6.
Проблема существовала и раньше. IE 5.5, например, умирал очень долго. Так что не стоит надеяться на девятый IE. Он может казаться неплохим сейчас, но через 10 лет мы его будем проклинать :)
Вы хоть поняли, что сказали? В январе был ещё Chromium 4-5, тогда как сейчас на дворе Google Chrome 7-9.
Не знаю, что там Fedora для Red Hat, но Chromium для разработчиков Google Chrome — альфа-версия.
Только вот совсем не понятно все-таки мне зачем это надо, если можно просто редиректить на https и все, если тебе так сильно нужен https, а на http чтоб ничего кроме 301 редиректа и не было…
Я так понимаю затем, что если кто-то стоит посередине, то в момент этого самого редиркета он клиенту ничего не отправит. А установит шифрованное соединение с сервером. И потом будет два соединения — нешифрованное от клиента до человека-по-середине и шифрованное от человека-по-середине до сервера.
Если с сервака Сразу пойдет шифрованный траф, то как его прочитать? О_о
Ведь сначала надо договориться об алгоритме шифрования, сделать ключ… А клиент знать не знает про это. Он же по http соединяется.
Хорошая MitM будет вестись с применением скомпрометированного корневого сертификата. И на уровне провайдера.
То есть для любого устанавливаемого защищенного соединения будет сгенерирован подходящий сертификат, подписанный скомпрометированным (или добавленным в систему корневым) сертификатом.
Пользователь не только не сможет предотвратить такой атаки, но и даже ее не заметит.
Кстати для уменьшения click-through insecurity реализация данного стандарта тоже не сильно поможет. Пользователь просто запустит другой браузер, который «работает».
Ну для этого надо как минимум скомпроментированный корневой сертификат… как показал опыт Stuxnet конечно можно много чего откопать, но все-таки это сложно…
HSTS будет внедрён в Firefox и Google Chrome