Jaka jest różnica między implementacją protokołu APR w protokole SSL a implementacją JSSE protokołu SSL w TOMCAT5.5

Question

Konfiguruję protokół SSL, aby obsługiwał protokół HTTPS w TOMCAT 5.5, dlatego odwołałem się do http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html, który opisuje sposób implementacji protokołu SSL.

W tym dokumencie opisano dwa sposoby wdrożenia SSL, a mianowicie implementację APR i implementację JSSE. Zastanawiam się, jaka jest między nimi różnica, w tym ich wady i zalety.

Answer 1

Różnica polega na tym, że JDK używa własnej implementacji protokołu SSL, podczas gdy APR używa tego, co jest zainstalowane na komputerze, tj. OpenSSL w większości przypadków.

Jeśli masz mały lub średni ruch na https, rozwiązanie Java jest w porządku, ale przy bardzo dużym obciążeniu (np. Gdy większość stron działa na https), rodzime rozwiązanie OpenSSL jest znacznie lepsze i może zostać ponownie skompilowane i zoptymalizowany, aby działał jeszcze szybciej i zużywał mniej zasobów. Główną wadą APR + OpenSSL jest jednak to, że wymaga ona więcej konfiguracji i strojenia + testowania, wersja Java działa po prostu z pudełka.

Zazwyczaj używam domyślnego rozwiązania Java SSL razem z narzędziami do monitorowania, a jeśli ruch staje się ciężki, niż i tylko staram się dostroić rozwiązanie APR.

Answer 2

Podczas korzystania z APR Tomcat może używać silnika OpenSSL, który jest podatny na błąd Heartbleed (http://heartbleed.com). Wtedy można przełączyć w server.xml z APR:

<-- Define a APR SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector protocol="org.apache.coyote.http11.Http11AprProtocol" port="8443" .../>

do realizacji Java SSL, który nie jest podatny przez ten błąd:

<-- Define a blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector protocol="org.apache.coyote.http11.Http11Protocol" port="8443" .../>

Lub jeśli chcesz aby mimo wszystko używać APR, upewnij się, że korzystasz z biblioteki Natywnej Tomcat, która została skompilowana z wersją OpenSSL, która nie jest podatna na Heartbleed (OpenSSL 1.0.1g lub wyżej) patrz https://issues.apache.org/bugzilla/show_bug.cgi?id=56363.

Answer 3

wersja Tomcat mniej niż 5.5.29 robi nie wsparcie atrybut nowy łącznik „allowUnsafeLegacyRenegotiation”, a jeśli używasz starą maszynę Javy (JVM 1.6 lub wcześniej bez poprawek zabezpieczeń) i nie chcesz zaktualizować ani Java ani Tomcat jedynym sposób - jest użycie APR. Patrz:

About security patches against RFC 5746 CVE-2009-3555

About Tomcat patches

About MITM vulnerability