Apache Cipher-Obskurität

Lord Gurke

Lord Gurke

Nur echt mit 32 Zähnen
Hallo zusammen,

ich versuche gerade einem Apache (httpd) unter CentOS 6.5 eine SSL-Cipherliste zu konfigurieren.
Allerdings stehe ich gerade auf dem Schlauch, warum das nicht in die Realität übernommen wird...

Ich habe folgendes konfiguriert:
Code: 
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AES:EECDH+ECDSA+SHA256:EECDH+aRSA-RC4:EDH+aRSA+AES:EECDH+AES:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4:!EXP:!PSK:!SRP:!DSS:!SEED:!CAMELLIA

Laut openssl müssten dabei folgende Ciphers bei rausfallen:
Code: 
~#: openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AES:EECDH+ECDSA+SHA256:EECDH+aRSA-RC4:EDH+aRSA+AES:EECDH+AES:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4:!EXP:!PSK:!SRP:!DSS:!SEED:!CAMELLIA'
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1


Wenn ich dann versuche, mich z.B. mit "ECDHE-ECDSA-AES256-GCM-SHA384" zu verbinden bekomme ich einen Handshake-Fehler - mit "DHE-RSA-AES128-SHA256" hingegen bekomme ich meine Verbindung:

Code: 
~#: openssl s_client -tls1_2 -connect xxx.xxx.xxx.xxx:https -cipher 'ECDHE-ECDSA-AES256-GCM-SHA384'
CONNECTED(00000007)
140309043812168:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40
140309043812168:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:

Es gibt keine weiteren Konfigurationsdateien, in denen Ciphers konfiguriert werden, zudem habe ich das bereits testweise innerhalb des VHost-Blocks eingefügt. Und wenn ich eintrage, dass ich ausschließlich AES+RC4 haben will, dann wird das auch tatsächlich so übernommen.
Muss ich irgendwas spezielles konfigurieren, wenn ich elliptische Kurven haben will resp. muss Apache dafür anders kompiliert werden?
Momentan läuft dort die Version aus den CentOS-Repositories.


Übersehe ich etwas?

Danke!
 
If you want to deploy perfect forward secrecy and you use a RedHat, Centos or Fedora based system you likely won’t be able to do so without building your own OpenSSL. This is because by default the OpenSSL packages for these systems do not include ECC or ECDH and when web-servers like apache and Nginx are built against libraries that do not support them they obviously omit support for the algorithms.
Click to expand...
=> http://unmitigatedrisk.com/?p=371

Sieht also nicht gut aus, du musst nicht nur OpenSSL sondern eventuell auch Apache neu kompilieren und ersetzen.
 
Hmpf.... Danke!
Scheint mit diesem komischen FIPS-Patch von Redhat/CentOS zu tun zu haben. Klar, wenn die amerikanische Regierung eines nicht will, dann dass jemand mit elliptischen Kurven seine Schlüssel austauscht :rolleyes:
Ich baue jetzt mal den FIPS-Patch aus und hoffe, dass es reicht.
Wenn nicht muss ich wohl nochmal darüber sinnieren ob mir DHE auch reicht oder ob es nicht sinnvoller ist auf eine andere Distri zu wechseln :(
 
Ich habe mit CentOS/RHEL 6.5 zwar noch nicht getestet, aber meines Wissens wurde damit ja auf eine aktuelle OpenSSL 1.0.1 hochgezogen - die Voraussetzungen sollten passen.

Hast Du dem Webserver auch ein ECDSA Zertifikat spendiert? Ist eher ungewöhnlich, die meisten CAs spucken aktuell nur RSA Zertifikate aus.

Klappt es mit ECDHE-RSA-AES256-SHA384? - wenn ja würde ich meinen, Dein Server verfügt nur über ein RSA und nicht über ein ECDSA Zertifikat.
 
dass jemand mit elliptischen Kurven seine Schlüssel austauscht
Click to expand...
Kannst ja versuchen ob es magisch funktioniert wenn du den DUAL_EC_DRBG verwendest, der sollte im FIPS-Patch sein. :D


ob mir DHE auch reicht
Click to expand...
Mein Hauptargument zum Verwenden von ECDHE mit AES ist der sehr niedrige Ressourcenverbrauch. Da AES eh in aktuellen CPU's (mit aktuellen Openssl-Libraries) hardware-unterstützt sein sollte, bleibt der 4096bit D-H Key-Exchange als Hauptlast. Er kann durch ein 256bit EC Key-exchange getauscht werden was auch SSL-DDoS bedeutend erschwert.

ob es nicht sinnvoller ist auf eine andere Distri zu wechseln
Click to expand...
Falls du auf Redhat (oder Derivaten) bleiben willst wäre noch ein minimaler Chroot (bspw ein Debian debootstrap) mit DotDeb's Nginx als SSL-Terminator eine Lösung. Ich würde eh generell empfehlen Nginx davor zu schalten. Nicht nur dass man mit LuaJIT (sehr fricklig auf zu setzen...) alles Mögliche darin realisieren kann, sondern er ist gegen viele HTTP-Angriffe mehr oder weniger immun.

[EDIT]

Hast Du dem Webserver auch ein ECDSA Zertifikat spendiert?
Click to expand...
Das ist nicht notwendig. Erhöht zwar die Sicherheit, allerdings auf Kosten der Kompatibilität zu einer langen Liste an Clients.
Ich verwende aktuell selber TLS 1.2 mit ECDHE_RSA und AES_256_CBC auf einem 4096bit RSA Zertifikat (arme CPU) mit SHA1 da dies nach Tests nicht nur sicher sondern auch generell unterstützt ist. Als Fallback gibts dann die üblichen Verdächtigen.
 
Last edited by a moderator:
Wie funktioniert ECDSA ohne ECDSA Zertifikat?
Der Server muss ja irgendwie seine Identität nachweisen, ohne ECDSA Zertifikat wird ihm das nicht gelingen. Wenn der Server nur über ein RSA Zertifikat verfügt, wird man auch RSA zum Nachweis der Identität verwenden müssen.

Nachtrag: Deine Aussage "das ist nicht notwendig" bezieht sich eventuell auf die Frage, ob Forward Secrecy ohne ECDSA nutzbar ist - klar, da bin ich ganz bei Dir, es ist ECDHE_RSA genausogut für Forward Secrecy geeignet wie ECDHE-ECDSA - aber Lord Gurke hat ja explizit ECDHE-ECDSA testen wollen, was meines erachtens eben ohne ECDSA Zertifikat am Webserver nicht funktionieren kann.
 
Last edited by a moderator:
Spendet... spendet für eine Tasse Kaffee =)
Natürlich, du hast Recht. Ich habe den ECDSA-Teil absolut übersehen.
 
gunnarh said:
Ich habe mit CentOS/RHEL 6.5 zwar noch nicht getestet, aber meines Wissens wurde damit ja auf eine aktuelle OpenSSL 1.0.1 hochgezogen - die Voraussetzungen sollten passen.
Click to expand...
Da läuft ein "OpenSSL 1.0.1e-fips 11 Feb 2013" - mich macht dieses Suffix "-fips" ein wenig stutzig. Irgendwo bin ich über die Aussage gestolpert, dass in FIPS elliptische Kurven keine Erwähnung finden und zwecks Zertifizierung ausgebaut/deaktiviert werden mussten. Andere Quellen behaupten, es hätte mit Patent-Bedenken zu tun (die mir relativ egal wären, denn das angesprochene Patent wurde nur in Nordamerika und nicht innerhalb der EU angemeldet).[/QUOTE]

gunnarh said:
Hast Du dem Webserver auch ein ECDSA Zertifikat spendiert? Ist eher ungewöhnlich, die meisten CAs spucken aktuell nur RSA Zertifikate aus.
Click to expand...
Ist ein Thawte SSL123 - ein solches habe ich auch auf meinem Debianischen Mailserver, der mir ohne Probleme Kurven zieht.
Allerdings - und das müsste ich mal testen - wurde der Key für das Webserver-Zertifikat auf einem CentOS 5 erzeugt, wo EC nicht verfügbar war. Tendenziell wäre es also denkbar dass weniger das Zertifikat als der Schlüssel das Problem darstellt, da werde ich mal ansetzen und testweise das funktionierende Mailserver-Zertifikat auf den Webserver holen!
Wobei auch der Mailserver (wie angesprochen) kein ECDSA unterstützt - könnte aber auch an der Serverkonfiguration liegen, da müsste ich mal reinschauen.

gunnarh said:
Klappt es mit ECDHE-RSA-AES256-SHA384? - wenn ja würde ich meinen, Dein Server verfügt nur über ein RSA und nicht über ein ECDSA Zertifikat.
Click to expand...
Nicht wirklich :(
Habe inzwischen dem Apache erklärt, dass es mir egal ist was er tut und er sämtliche Protokolle und Ciphers zulassen soll. Irritierenderweise kann der OpenSSL-Client auf der selben Maschine zwar Verbindungen mit EC aufbauen, aber der Webserver schließt sämtliche Cipher aus in denen das Wort "EC" vorkommt.
Entweder hat der Paketverwalter beim Apache irgendwas verbockt oder es liegt doch am Zertifikat!
Werde das mal wie gesagt mit dem Mailserverzertifikat testen, da weiß ich dass es geht :)



d4f said:
Kannst ja versuchen ob es magisch funktioniert wenn du den DUAL_EC_DRBG verwendest, der sollte im FIPS-Patch sein. :D
Click to expand...
Das war der Patch, der zielsicher zum Segfault führte? :p


d4f said:
Mein Hauptargument zum Verwenden von ECDHE mit AES ist der sehr niedrige Ressourcenverbrauch. Da AES eh in aktuellen CPU's (mit aktuellen Openssl-Libraries) hardware-unterstützt sein sollte, bleibt der 4096bit D-H Key-Exchange als Hauptlast.
Click to expand...
Jaein...
Ich habe gesehen wie erstaunlich schnell AES direkt "in" der CPU berechnet werden kann - allerdings bekomme ich es auf Biegen und Brechen nicht in eine virtuelle Maschine reingereicht.
KVM kann mir zwar die CPU 1:1 reinreichen, dabei verschwinden dann aber logischerweise die Energiesparfunktionen, die Virtualisierungsfunktionen - und AES. Eine definitive Aussage zu den Hintergründen habe ich nicht gefunden, was ich mir jedoch zusammengetragen habe deutet darauf hin, dass dies eine potentielle Sicherheitslücke wäre, weil dazu ja der Schlüssel vom Gast in die CPU getragen werden müsste und dort zumindest für den Host unter bestimmten Umständen tendenziell auslesbar wäre.
Könnte aber auch daran liegen dass mein i7 schlichtweg keine "virtualisierungsfähige" AES-Implementation hat und die den teureren Xeons vorbehalten ist. Leider habe ich keinen Xeon mit AES-NI mit dem ich das testen könnte - der X3440 in den Produktivservern hat das noch nicht ;)


Nachtrag: Wenn genug Geld für Kaffee zusammengespendet wurde - ich täte auch einen nehmen!
Man beachte die Uhrzeiten der Posts..... ;)
 
Gerade getestet: Es liegt leider offenbar nicht am Zertifikat :(
Das sind die einzigen Ciphers mit denen ich eine Verbindung bekomme:
Code: 
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
ADH-AES256-GCM-SHA384
ADH-AES256-SHA256
ADH-AES256-SHA
ADH-CAMELLIA256-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA256-SHA
EDH-RSA-DES-CBC3-SHA
ADH-DES-CBC3-SHA
DES-CBC3-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-SEED-SHA
DHE-RSA-CAMELLIA128-SHA
ADH-AES128-GCM-SHA256
ADH-AES128-SHA256
ADH-AES128-SHA
ADH-SEED-SHA
ADH-CAMELLIA128-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
SEED-SHA
CAMELLIA128-SHA
ADH-RC4-MD5
RC4-SHA
RC4-MD5
EDH-RSA-DES-CBC-SHA
ADH-DES-CBC-SHA
DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-ADH-DES-CBC-SHA
EXP-DES-CBC-SHA
EXP-RC2-CBC-MD5
EXP-ADH-RC4-MD5
EXP-RC4-MD5
Sieht ganz danach aus, als wenn schlichtweg das ganze EC-Zeug von den Redhat-Fritzen rausgeworfen oder deaktiviert wurde :(


Nachtrag: OpenSSL unter CentOS 6 kann doch Elliptic Curve!
Der httpd wird jedoch nur in Version 2.2.15 ausgeliefert und enthält somit keine Untertützung dafür - die ist erst im 2.4.x-Zweig hinzugekommen. Entgegen anderslautender Gerüchte wurde diese Funktionalität zumindest von Redhat auch nicht in 2.2 portiert...
Bleibt also erstmal nur der von d4f vorgeschlagene SSL-Proxy ;)
 
Last edited by a moderator:
Hi,

die hatte ich vorhin in meiner Verzweiflung schon probiert - allerdings bricht dann leider das totale Chaos auf dem System aus :(
Die installieren den 2.4er Apache nach /opt/rh/httpd - weil man dann den 2.2er Apache nicht damit kaputtmacht.
Spoiler: Doch, der geht dabei trotzdem kaputt ;)
Die Config habe ich nach kurzer Suche dann auch irgendwann gefunden, das versprochene Startscript leider nicht...
Zum Testen ganz OK, aber beim besten Willen keine Dauerlösung.


Obskurerweise habe ich nun ein neues Phänomen was ich nicht richtig deuten kann:
Ich habe nginx installiert (aus dem von den nginx-Menschen bereitgestelltem Repository), konfiguriert u.s.w. - und bekomme mit dem Dingen ebenfalls keine ECDH-Ciphers zum laufen :confused:

Teste ich es mit OpenSSL (Originalversion von CentOS) als Server, klappt das Problemlos mit dem selben Key/Zertifikat was nginx auch benutzt:

Code: 
]# openssl s_server -accept 444 -cert testcert.pem
---------
]# openssl s_client -connect 127.0.0.1:444 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'
CONNECTED(00000003)
....
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
Probiere ich diese Verbindung auf nginx (ALLE Ciphers aktiviert):

Code: 
~# openssl s_client -connect 127.0.0.1:443 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'
CONNECTED(00000003)
139670223107752:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741:
Ich deute das mal so, dass es weder am Zertifikat noch an den OpenSSL-Libraries liegen kann.
Bin ich jetzt doof oder die Paketbetreuer?
Installiert ist nginx 1.4.4 - übereinstimmend mit den Prophezeihungen der Entwickler sollte spätestens ab dem 1.1er Zweig ECDH problemlos möglich sein.

Ich habe ja durchaus Hoffnung dass sich nginx unter CentOS weniger aufwändig bauen lässt als der Apache httpd - aber eigentlich dachte ich dass die offiziellen RPMs von nginx nicht verstümmelt gebaut sein sollten...
 
ERFOLGSBERICHT:

Noja, "Erfolg" ist Definitionssache... Ich habe es nun aber ans Laufen bekommen. Mit dem Hintergedanken: "Einmal. Ein EINZIGES MAL...!! NUR EIN EINZIGES MAL mit Profis...." :rolleyes: :cool: ;)

Nginx kann in der fertig bereitgestellten RPM-Version [1] nur mit ECDSA Kurven ziehen, dafür braucht es aber einen entsprechenden Schlüssel. Über den Signaturwillen dazu schweigen sich die großen CAs auf den Hilfeseiten aus, allerdings existieren in den Wurzelzertifikaten von Thawte und Symantec EC-Zertifikate, was mich glauben lässt dass die das schon signieren wenn man es ihnen vorsetzt.

Wenn man sich von Nginx nun das Source-RPM holt und ohne Veränderung selbst nochmal zusammenbaut, funktioniert das mit ECDHE auf einmal. Und ich verwende momentan auch die originale OpenSSL-Library von CentOS 6.5, in der die ECDHE- und ECDSA-Ciphers wieder enthalten sind.

Vermutlich hat der Paket-Maintainer das Nginx-Paket auf einem CentOS 6.4 oder älter gebaut...


[1] http://nginx.org/packages/rhel/6/x86_64/RPMS/
 
Nur nochmal zur Klarstellung: Eine ECC Zertifikat benötigst Du nur, wenn du ECDSA verwenden möchtest. ECDHE - was Du offenkundig wegen Forward Secrecy einsetzen möchtest - lässt sich aber freilich auch mit RSA oder DSA kombinieren, muss also nicht zwingend mit ECDSA genutzt werden.
 
Korrekt, das hatte ich wohl etwas missverständlich geschrieben...
Ich wollte damit sagen, dass Nginx Elliptic Curve-Schlüsselaustausch in der offiziellen RPM-Version nur in Verbindung mit ECDSA unterstützt und natürlich auch nur wenn ein ECDSA-Schlüssel vorhanden ist - sonst werden garkeine ECDH-Cipher angeboten.
In der selbstgebauten Version funktioniert dann ECDH auch in Verbindung mit RSA, wie man es haben will.
 
Test mit Ubuntu 12.04 und Default pakets

es tut mir leid, dass ich das Thema wieder ausgrabe, aber ich habe mich die letzten Tage selber damit beschäftigt und fand diesen Blogeintrag recht gut:

http://www.kuketz-blog.de/nsa-abhoersichere-ssl-verschluesselung-fuer-apache-und-nginx/

Leider konnte ich das nicht so umsetzten, da ich einen Apache 2.2.22 (Ubuntu 12.04) mit OpenSSL 1.0.1 14 Mar 2012 einsetze.

Als Cipher habe ich mich für folgende Entschieden:
Code: 
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

Ergebnis bei ssllabs:

https://www.ssllabs.com/ssltest/analyze.html?d=sandwolke.net

Geht das noch zu steigern? Bzw. gibt es für Ubuntu 12.04 neue Versionen des Apache2 Servers bzw. von OpenSSL ohne selber zu kompilieren?

Grüße

Lyn

PS: Mit einem IE6 unter Windows 2000 habe ich keine Verbindung mehr zu der Domain aufbauen können (aber wer sowas einsetzt, dem ist eh nicht mehr zu helfen :) Den IE11 unter Windows 8.1 konnte ich nicht testen. Soll ja damit nach dem zweiten Aufruf klappen. Da momentan unter der Domain aber mein persönlicher OwnCloud Speicher läuft ist das erstmal nebensächlich.
 
You must log in or register to reply here.
Back
Top