Ile narzutów nakłada SSL?

168

Wiem, że nie ma jednej, szybkiej odpowiedzi, ale czy istnieje ogólne przybliżone oszacowanie rzędu wielkości dla narzutu szyfrowania SSL w porównaniu z komunikacją niezaszyfrowaną przez gniazdo? Mówię tylko o przetwarzaniu komunikacji i czasie połączenia, nie licząc przetwarzania na poziomie aplikacji.

Aktualizacja

Jest pytanie o HTTPS i HTTP , ale jestem zainteresowany szukaniem niżej w stosie.

(Zastąpiłem wyrażenie „rząd wielkości”, aby uniknąć nieporozumień; używałem go raczej jako nieformalnego żargonu niż w formalnym sensie CompSci. Oczywiście, gdybym miał to na myśli formalnie, jako prawdziwy maniak myślałbym raczej binarnie niż dziesiętny! ;-)

Aktualizacja

Załóżmy, że na żądanie w komentarzu mówimy o wiadomościach o dużej wielkości (zakres od 1 000 do 10 000) przez trwałe połączenia. Zatem konfiguracja połączenia i narzut pakietów nie są znaczącymi problemami.

joel.neely
źródło
Możesz spojrzeć na to podobne pytanie .
Darin Dimitrov
1
Czy możesz bardziej scharakteryzować swoją aplikację? Na przykład, czy ustanawia wiele krótkotrwałych połączeń? Jak duża jest pojedyncza wiadomość, gdy jest połączona? (Np. Może opróżniasz każde naciśnięcie klawisza za pomocą Telnetu przez tunel SSL, a może kopiujesz 1 TB plików dziennika.)
erickson

Odpowiedzi:

178

Rząd wielkości: zero.

Innymi słowy, po dodaniu TLS nie zobaczysz, że przepustowość spadnie o połowę ani nic podobnego. Odpowiedzi na pytanie „zduplikowane” koncentrują się głównie na wydajności aplikacji i porównaniu z narzutem SSL. To pytanie w szczególności wyklucza przetwarzanie aplikacji i ma na celu porównanie tylko wersji bez SSL z SSL. Chociaż optymalizacja ma sens z całościowego spojrzenia na wydajność, nie o to chodzi w tym pytaniu.

Głównym narzutem SSL jest uzgadnianie. Tam właśnie dzieje się kosztowna asymetryczna kryptografia. Po negocjacjach używane są stosunkowo wydajne szyfry symetryczne. Dlatego bardzo pomocne może być włączenie sesji SSL dla usługi HTTPS, w której nawiązywanych jest wiele połączeń. W przypadku długotrwałego połączenia ten „efekt końcowy” nie jest tak istotny, a sesje nie są tak przydatne.


Oto interesująca anegdota. Kiedy Google przestawił Gmaila na HTTPS, nie były potrzebne żadne dodatkowe zasoby; bez sprzętu sieciowego, bez nowych hostów. To tylko zwiększyło obciążenie procesora o około 1%.

erickson
źródło
6
Jak „włączyć sesje SSL dla usługi HTTPS”? Jakie jest dobre źródło informacji na ten temat?
Justin Vincent
1
Włączenie sesji SSL zależy od serwera. Przeczytaj instrukcję obsługi swojego serwera.
erickson
7
@Bart van Heukelom - Keep-alive pomoże dłużej utrzymać otwarte gniazdo (i połączenie SSL), co pomaga. Jednak sesje SSL powodują, że negocjowane parametry kryptograficzne są „zapamiętywane” z gniazda do gniazda. Tak więc utrzymywanie aktywności HTTP byłoby przydatne do załadowania pojedynczej strony internetowej z zawartością, do której się odwołuje, ale po kilku sekundach połączenie to zostanie zamknięte. Powiedzmy, że trzy minuty później, gdy zostanie pobrana kolejna strona, sesja SSL umożliwia ponowne nawiązanie połączenia SSL bez powtarzania pełnego uzgadniania. W szczególności można pominąć powolną wymianę kluczy z kryptografią klucza publicznego.
erickson,
2
@ Tony, czy masz jakieś przykłady z prawdziwego świata, w których TLS dodaje więcej niż kilka procent narzutu? Moja odpowiedź jest równie ogólna jak pytanie. Jeśli masz inne podejście, udostępnij je.
erickson,
3
@Tony Widziałem, że zwykłe gniazda przewyższają gniazda SSL 42-krotnie pod względem przestrzeni podczas zapisywania pojedynczego bajtu na raz, co jest najgorszym przypadkiem. Nigdy nie widziałem 250x. Przeprowadziłem obszerny eksperyment w Internecie z 1700 punktami danych, w którym ogólny wynik był taki, że gniazda z tekstem jawnym były nie lepsze niż trzy razy szybciej niż SSL, używając programowania nie bardziej wyrafinowanego niż buforowanie i opróżnianie. JSSE, prawdopodobnie Java 5 ze względu na datę eksperymentu.
Markiz Lorne,
39

Drugi @erickson: Kara za czystą prędkość przesyłania danych jest znikoma. Nowoczesne procesory osiągają przepustowość kryptowalut / AES na poziomie kilkuset Mb / s. Więc jeśli nie korzystasz z systemu o ograniczonych zasobach (telefon komórkowy), protokół TLS / SSL jest wystarczająco szybki, aby przesyłać dane.

Należy jednak pamiętać, że szyfrowanie znacznie utrudnia buforowanie i równoważenie obciążenia. Może to spowodować ogromny spadek wydajności.

Ale konfiguracja połączenia naprawdę zatrzymuje pokaz dla wielu aplikacji. Przy niskiej przepustowości, dużej utracie pakietów, połączeniach z dużymi opóźnieniami (urządzenie mobilne na wsi) dodatkowe obiegi wymagane przez TLS mogą spowodować, że coś powolnego stanie się bezużyteczne.

Na przykład musieliśmy zrezygnować z szyfrowania dostępu do niektórych naszych wewnętrznych aplikacji internetowych - były one prawie bezużyteczne, jeśli były używane z Chin.

max
źródło
20
Patrząc z perspektywy 4 lat: Chiny mogły po prostu celowo zepsuć cały ruch SSL / TLS.
max
3
Chińskie cenzurowanie internetu i próby podsłuchiwania ruchu każdego z nas nie są niczym nowym. Jednak patrząc z perspektywy 4 lat, można by pomyśleć, że to NSA MITMing wkracza na Twoją stronę.
Eugene Beresovsky
Kluczem do niestabilnych połączeń jest jednorazowe skonfigurowanie szyfrowania, a następnie unikanie ponownych negocjacji, chyba że jest to naprawdę konieczne, i umożliwienie obu stronom zmiany adresów IP w dowolnym momencie bez mrugnięcia okiem. (OpenVPN to obsługuje.) IT pomaga umożliwić fragmentację, ponieważ MTU może być bardzo zawodne i wręcz nieuczciwe.
Evi1M4chine
12

Zakładając, że nie liczysz konfiguracji połączenia (jak wskazałeś w swojej aktualizacji), w dużym stopniu zależy to od wybranego szyfru. Narzut sieci (pod względem przepustowości) będzie znikomy. Narzut procesora będzie zdominowany przez kryptografię. Na moim mobilnym Core i5 mogę zaszyfrować około 250 MB na sekundę za pomocą RC4 na jednym rdzeniu. (RC4 jest tym, co powinieneś wybrać, aby uzyskać maksymalną wydajność). AES jest wolniejszy, zapewniając „tylko” około 50 MB / s. Tak więc, jeśli wybierzesz poprawne szyfry, nie uda ci się utrzymać pojedynczego rdzenia zajęty narzutem kryptograficznym, nawet jeśli masz w pełni wykorzystaną linię 1 Gbit. [ Edycja : RC4 nie powinno być używane, ponieważ nie jest już bezpieczne. Jednak obsługa sprzętowa AES jest obecnie obecna w wielu procesorach, co sprawia, że ​​szyfrowanie AES jest naprawdę szybkie na takich platformach.]

Jednak ustanowienie połączenia jest inne. W zależności od implementacji (np. Obsługa fałszywego startu TLS), doda okrążenia, które mogą powodować zauważalne opóźnienia. Dodatkowo drogie szyfrowanie odbywa się przy pierwszym nawiązaniu połączenia (wspomniany powyżej procesor może zaakceptować tylko 14 połączeń na rdzeń na sekundę, jeśli głupio użyjesz kluczy 4096-bitowych i 100, jeśli używasz kluczy 2048-bitowych). Przy kolejnych połączeniach często ponownie wykorzystuje się poprzednie sesje, unikając kosztownego krypto.

Podsumowując:

Transfer przy nawiązanym połączeniu:

  • Opóźnienie: prawie żadne
  • Procesor: pomijalny
  • Przepustowość: pomijalna

Pierwsze nawiązanie połączenia:

  • Opóźnienie: dodatkowe przejazdy w obie strony
  • Przepustowość: kilka kilobajtów (certyfikaty)
  • Procesor na kliencie: średni
  • Procesor na serwerze: wysoki

Kolejne zestawienia połączeń:

  • Opóźnienie: dodatkowa podróż w obie strony (nie wiem, czy jedna, czy wiele, może zależeć od implementacji)
  • Przepustowość: pomijalna
  • CPU: prawie żaden
Jan Schejbal
źródło
Ważna uwaga: nikt nie powinien nigdy więcej używać RC4. Protokół należy uznać za uszkodzony, a transmisję RC4 z nim należy traktować jako odpowiednik transmisji nieszyfrowanej, przynajmniej ze względu na bezpieczeństwo organizacji szpiegowskich. Obecnie coś takiego jak chacha20-poly1305 jest zdecydowanie zalecane do szyfrowania zbiorczego ze względu na jego niezależność od takich organizacji.
Evi1M4chine