Крис Томпсон упоминает о кэшировании в браузере, но это легко исправить в браузере. При переключении всего на HTTPS невозможно исправить прокси-кэширование. Поскольку HTTPS полностью зашифрован, прозрачные прокси-серверы HTTP не работают. Есть много мест, где прозрачное проксирование может ускорить процесс (например, на границах NAT).
Работа с дополнительной пропускной способностью от потери прозрачного прокси, вероятно, выполнима - якобы HTTP-трафик в любом случае тривиален по сравнению с p2p, так что прозрачные прокси не являются единственной вещью, поддерживающей интернет в сети. Это безвозвратно увеличит задержку и сделает косую черту еще хуже, чем сейчас. Но затем с облачным хостингом, оба могут быть решены с помощью технологий. Конечно, «безопасный сервер» приобретает иной смысл в облачном хостинге или даже при других формах децентрализации контента в сети, таких как akamai.
Я не думаю, что загрузка процессора настолько значительна. Конечно, если ваш сервер в настоящее время ограничен ЦП, по крайней мере, некоторое время, то переключение всего трафика с HTTP на HTTPS убьет его до смерти. Некоторые серверы могут решить, что HTTPS не стоит денежных затрат на процессор, который может справиться с нагрузкой, и они будут препятствовать буквально каждому принять его. Но я сомневаюсь, что это будет серьезным барьером надолго. Например, Google уже пересек его и радостно обслуживает приложения (хотя и не поиски) как https без суеты. И чем больше серверов работают над соединением, тем меньше пропорциональной дополнительной работы требуется для SSL-защиты этого соединения. SSL может быть и аппаратно ускорен там, где это необходимо.
Существует также управленческая / экономическая проблема, заключающаяся в том, что HTTPS полагается на доверенные ЦС, а доверенные ЦС стоят денег. Существуют и другие способы создания PKI, кроме того, который фактически использует SSL, но есть причины, по которым SSL работает так, как он это делает. Например, SSH возлагает на пользователя ответственность за получение отпечатка ключа с сервера по защищенному побочному каналу, и это результат : некоторые пользователи не считают, что уровень неудобств оправдан его цель безопасности. Если пользователям не нужна безопасность, они не получат ее, если только они не смогут ее избежать.
Если пользователи просто автоматически нажимают «принять» для ненадежных SSL-сертификатов, то у вас их вполне может не быть, поскольку в наши дни атака «человек посередине» не намного сложнее, чем обычное прослушивание. Итак, опять же, существует значительный блок серверов, которые просто не интересны для оплаты (работающих) HTTPS.