RSA vs ECC (ECDSA) w certyfikatach SSL. Co wybrać i dlaczego?

Wybór algorytmu dla certyfikatu SSL/TLS przestał być dziś wyłącznie technicznym detalem.
W praktyce wpływa na:

• wydajność serwera,
• szybkość zestawiania połączeń TLS,
• kompatybilność ze starszymi urządzeniami,
• bezpieczeństwo długoterminowe,
• obciążenie CPU,
• a nawet koszty utrzymania infrastruktury przy dużym ruchu.

 Klient zamawiający certyfikat DigiCert praktycznie zawsze staje przed pytaniem:

 RSA czy ECC (ECDSA)?

odpowiedź brzmi:
„To zależy od środowiska, kompatybilności oraz oczekiwanego poziomu wydajności.”

 Poniżej znajdziesz techniczne porównanie obu rozwiązań wraz z realnymi rekomendacjami wdrożeniowymi.

Czym właściwie jest RSA i ECC?

RSA

RSA to klasyczny algorytm kryptografii asymetrycznej opracowany jeszcze w latach 70. Bazuje na trudności faktoryzacji dużych liczb pierwszych.
To obecnie najbardziej rozpowszechniony standard w certyfikatach SSL/TLS.

Najczęściej spotykane długości kluczy:

• RSA 2048 bit
• RSA 3072 bit
• RSA 4096 bit

RSA jest praktycznie uniwersalnie wspierany przez:

• stare systemy operacyjne,
• starsze przeglądarki,
• urządzenia embedded,
• stare load balancery,
• starsze JVM,
• stare urządzenia przemysłowe,
• stare Androidy i Windowsy.

ECC / ECDSA

ECC (Elliptic Curve Cryptography) wykorzystuje kryptografię krzywych eliptycznych.
W certyfikatach SSL najczęściej używany jest podpis:

• ECDSA

Najpopularniejsze krzywe:

• P-256
• P-384
• P-521

ECC osiąga taki sam poziom bezpieczeństwa jak RSA przy znacznie krótszych kluczach.
Przykładowo:

• ECC 256 bit = RSA 3072 bit
• ECC 384 bit = RSA 7680 bit
• ECC 521 bit = RSA 15360 bit

Największa różnica: wydajność. Tu ECC praktycznie nokautuje RSA.

Dlaczego?

• klucze są dużo krótsze,
• podpisy cyfrowe są mniejsze,
• handshake TLS wymaga mniej danych,
• operacje kryptograficzne są szybsze,
• zużycie CPU jest niższe.

Co to oznacza w praktyce?

ECC zapewnia:

1. Mniejsze obciążenie CPU, co jest bardzo ważne przy:
   • dużym ruchu HTTPS,
   • API,
   • CDN,
   • reverse proxy,
   • HAProxy,
   • Nginx,
   • Envoy,
   • Kubernetes ingress,
   • edge nodes,
   • IoT.
2. Szybszy handshake TLS, czyli:
   • szybsze otwieranie połączeń,
   • niższe latency (opóźnienie),
   • lepszy TTFB.
3. Mniejsze certyfikaty i pakiety TLS, a w efekcie:
   • mniej danych przesyłanych przez sieć,
   • mniejsze wykorzystanie przepustowości (bandwidth),
   • lepsza wydajność mobilna.
4. Lepsza skalowalność, szczególnie przy:
   • tysiącach TPS,
   • dużych platformach SaaS,
   • środowiskach cloud-native.

Dlaczego więc RSA nadal dominuje?

Bo kompatybilność nadal wygrywa. RSA to obecnie „bezpieczny wybór kompatybilnościowy”.
Starsze systemy mogą:

• nie wspierać ECDSA,
• mieć problemy z handshake,
• nie wspierać wybranych krzywych ECC,
• mieć stare biblioteki OpenSSL,
• nie obsługiwać nowoczesnych cipher suites.

Typowe problemy kompatybilnościowe ECC

Stare systemy Windows
Problemy mogą wystąpić m.in. na:

• Windows XP,
• Windows Server 2003,
• stare IE,
• stare .NET Framework.

Stare Androidy
Największe problemy:

• Android < 4.4,
• stare WebView,
• stare urządzenia embedded.

Stare urządzenia sieciowe
Problematyczne bywają:

• stare firewalle,
• stare load balancery,
• stare HSM,
• stare appliance VPN,
• stare drukarki,
• stare NAS-y.

Stare biblioteki OpenSSL
Problemy występują przy:

• OpenSSL < 1.0.2,
• bardzo starych dystrybucjach Linux.

Czy ECC jest dziś bezpieczniejsze niż RSA?

Technicznie:

• oba algorytmy są obecnie uznawane za bezpieczne,
• ale ECC osiąga ten sam poziom bezpieczeństwa przy dużo mniejszych kluczach.

Dodatkowo:

• RSA wymaga stale rosnących długości kluczy,
• ECC skaluje się znacznie efektywniej.

A co z odpornością na komputery kwantowe?

To ważne. Prawda jest taka: ani RSA, ani ECC nie są odporne na pełne komputery kwantowe.
Dlatego branża powoli przechodzi w kierunku:

• PQC (Post-Quantum Cryptography),
• hybryd PQC + ECC.

Czy DigiCert wspiera ECC?

Tak. I to bardzo dobrze. DigiCert posiada:

• własne rooty ECC,
• intermediate ECC,
• wsparcie dla ECC CSR,
• pełne wsparcie dla ECDSA certificates.

Największy błąd klientów to mylenie: RSA/ECC certyfikatu z RSA/ECDHE podczas handshake TLS.
To NIE jest to samo.

TLS 1.3 zmienia zasady gry

TLS 1.3 mocno promuje:

• ECDHE,
• nowoczesne krzywe,
• szybsze handshake.

Kiedy wybrać RSA?

RSA rekomendowany jest gdy:

• Potrzebujesz maksymalnej kompatybilności
• Obsługujesz starszych klientów
• Nie masz pewności co do środowiska klienta
• Masz legacy infrastructure

Kiedy wybrać ECC?

ECC rekomendowany jest gdy:

• Liczy się wydajność
• Masz nowoczesnych użytkowników
• Chcesz zmniejszyć obciążenie CPU
• Budujesz nowoczesną infrastrukturę cloud-native

Najlepsze rozwiązanie? Dual certificate deployment

Coraz więcej dużych organizacji wdraża dziś:

• RSA + ECC jednocześnie.

Serwer:

• prezentuje ECC nowoczesnym klientom,
• a RSA starszym urządzeniom.

Rekomendacja praktyczna dla klientów SSL24

Wybierz RSA gdy:

• obsługujesz klientów masowych,
• nie znasz środowiska odbiorców,
• potrzebujesz 100% kompatybilności,
• masz starszą infrastrukturę.

Wybierz ECC gdy:

• masz nowoczesne środowisko,
• liczysz na wysoką wydajność,
• obsługujesz duży ruch,
• zależy Ci na nowoczesnej kryptografii.

Dla większości klientów publicznych:
RSA nadal pozostaje najbardziej uniwersalnym wyborem.

Dla nowoczesnych platform:
ECC jest technicznie lepsze:

• szybsze,
• lżejsze,
• bardziej wydajne,
• bardziej przyszłościowe.

Dla dużych środowisk enterprise:
Najlepszym rozwiązaniem jest:

• równoległe wdrożenie RSA + ECC.

To obecnie złoty standard nowoczesnego TLS.