Сколько сетевых издержек добавляет TLS по сравнению с незашифрованным соединением?

Question

(Приблизительно) сколько еще бит данных должно быть передано по сети во время зашифрованного соединения по сравнению с незашифрованным соединением?

IIUC, после завершения квитирования TLS количество передаваемых битов равно числу передаваемых битов во время незашифрованного соединения. Это точно?

В качестве продолжения, передача большого файла по протоколу https значительно медленнее, чем передача этого файла по протоколу http, с учетом быстрых процессоров и тех же (идеальных) условий сети?

Answer 1

Я получил этот вопрос несколько раз, поэтому я решил написать небольшое объяснение накладных расходов с некоторыми номерами выборок, основанными на общем случае. Вы можете прочитать его в моем блоге на http://netsekure.org/2010/03/tls-overhead/.

Резюме из сообщения в блоге:

• Суммарные накладные расходы на создание нового сеанса TLS составляют в среднем около 6,5 тыс. Байт.
• Общий объем служебных данных для возобновления существующего сеанса TLS составляет в среднем около 330 байт.
• Общий объем служебных данных зашифрованных данных составляет около 40 байтов.

Answer 2

Короткий ответ: Ваш Milage может меняться (YMMV) - все зависит от вашей модели трафика. Есть ряд факторов, которые необходимо учитывать:

• Дополнительные рукопожатия и сертификаты добавят 4-6 КБ к потоку TCP, что также приведет к увеличению количества кадров Ethernet, передаваемых по проводам
• Клиенты должны загрузить список отзыва сертификатов . Некоторые инструменты, такие как cURL, пропускают этот шаг. Браузер может кэшировать crl, однако он обычно не ассоциируется с ним долго. Verisign истекает через четыре минуты. В моем тестировании Safari в Windows загружал один и тот же файл размером 91 КБ дважды.
• Возобновление сеанса TLS позволяет избежать обмена открытым ключом при обмене ключами, а также при проверке сертификата.
• HTTP keep-alive будет держать сокет открытым, так же как http, но имеет большую экономию, когда сокетом является TLS.
• Сжатие SSL * Поддержка 1021 * начинает обнаруживаться на стороне сервера, но AFAIK, большинство браузеров пока не реализуют это. Кроме того, если вы уже сжимаете на уровне http, здесь мало что получится. Потенциально большие выгоды могут быть получены, если клиент отправляет большие объемы текста на сервер, который обычно не сжимается на уровне http.

Answer 3

Что касается служебных данных, вычисленных в http://netsekure.org/2010/03/tls-overhead/, как вы думаете, вы могли пропустить вектор инициализации (IV) для AES в режиме CBC? Так как это AES128, я думаю, что к накладным расходам нужно добавить 16 байтов IV, что в сумме составляет 56 вместо 40 байтов.

Answer 4

на порядок. Смотрите это . Это не слишком важно, если защищаемая информация заслуживает защиты. И помните, что скорость процессора может только возрасти, поэтому производительность будет улучшаться.