IT-weblog

All der tägliche Frust und Schweiß der IT-Branche

Schlagwort: SSL

Tomcat mit SSL bestücken

Da mir OpenSSL irgendwie näher ist und mit dem Tomcat native Dingens das auch unterstützt ist, also mal eben ein Zertifikat erstellen lassen und mit ein paar Zeilen im server.xml eingebaut.

<Connector port=“443″ maxHttpHeaderSize=“8192″
maxThreads=“150″
enableLookups=“false“ disableUploadTimeout=“true“
acceptCount=“100″ scheme=“https“ secure=“true“
SSLEnabled=“true“
SSLCertificateChainFile=“${catalina.base}/conf/ssl/sub.class1.server.ca.pem“
SSLCertificateFile=“${catalina.base}/conf/ssl/cert.pem“
SSLCertificateKeyFile=“${catalina.base}/conf/ssl/key.pem“ />

Allerdings dürfte das nicht alles gewesen sein. Denn ein schneller Test bei SSLlabs vergibt die Note F und man ist sicherheits-technisch durchgefallen:

This server supports anonymous (insecure) suites (see below for details). Grade set to F.

Wer auch immer die Default-Werte beim Tomcat zu verantworten hat, darf sich die high5 bei mir persönlich abholen.

Also zwei Zeilen mehr rein in das Connector-Tag im server.xml:

SSLHonorCipherOrder=“true“
SSLCipherSuite=“ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW“

Das ergibt im Test schon mal Note B, aber es ist immernoch Compression aktiviert, die auch nicht gut tut. Also noch eine Zeile mehr hinein:

SSLDisableCompression=“true“

Nun gibt es Note A (100,90,80,90 für Eingeweihte) und auch die ForwardSecrecy wird angeboten.

Also alles nicht mal eben zu realisieren, man muß schon jeden Schritt testen.

Schade drum.

ownCloud mit sicherem SSL

Will man nicht gerade alles selber compilieren, dann nimmt der bequeme Admin gerne auch eine normale main-stream-Distribution. In dem Falle Debian 7.1 was so ziemlich jeder VHost Anbieter können sollte. Dabei allerdings einen Webserver zu finden, der PFS beherrscht, also die Perfect forward secrecy, ist eine Baustelle für sich. Aktueller Stand der Lösung ist:

  • keinen Apache nutzen
  • nginx der Distribution nutzen
  • eintragen von ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  • eintragen von ssl_ciphers AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:RC4:HIGH:!MD5:!aNULL:!EDH;
  • eintragen von ssl_prefer_server_ciphers on;

Und dann noch ein allgemein gültiges Zertifikat von z.B. startssl geholt und dann letztendlich via ssltest das ganze geprüft:

 ssllabls1

 ssllabls2

XSS bei PayPal

Das zeigt wieder mal schön die Grenzen von SSL und erst recht von EV-SSL auf. Die ganzen Verschlüsselungen beziehen sich schließlich nur auf die Übertragungsstrecke und signieren in keinster Weise den Inhalt. Der Inhalt aber ist gerade das wichtige in Hinblick auf XSS, da diese Codefragmente ja direkt vom erlaubten Server geschickt werden.

Dagegen kann nur eine inhaltliche Signierung helfen, wie mal auf SigHTTP von mir angedacht wurde. Ich glaube es wird Zeit für eine erste IMplementierung dieser Idee. Wenn mannur mehr Zeit hätte.

Schade drum.

SSL ohne Verschlüsselung

SSL ohne VerschlüsselungEine kleine Warnung an alle, die SSL, HTTPS und Verschlüsselung in einen Topf werfen. Auch bei einer Webseite die via https angesteuert wird, kann man einzelne Informationen auf dem Weg abgreifen.

Zumindest der Servername wird im Klartext beim TLS-Handshake übertragen, obwohl man eigentlich direkt mit einer IP-Nummer kommunizieren wollte. Dies ist nicht zu verwechseln mit dem Host-Header im HTTP1.1 Standard, diese Zeile wird im SSL verschlüsselt übertragen. Bringt halt nur nichts, weil der Key im Klartext vorher versendet wurde.

Wer sich also schon mal gewundert hat, wie z.B. ein Verbindungsprotokoll erstellt wird, hat hier einen Ansatz.

Schade drum.

© 2017 IT-weblog

Theme von Anders NorénHoch ↑