Präambel: Die Humboldt-Universität zu Berlin, Unter den Linden 6, 10099 Berlin, im Folgenden als Humboldt-Universität bezeichnet, stellt für die Anwendung im Zusammenhang mit deutschen hoheitlichen Dokumenten, wie beispielsweise den neuen Personalausweis und den elektronischen Aufenthaltstitel, eine clientseitige eID-Basis-Software zum Bereitstellen der sogenannten eID-Funktionalität, d.h. Ermöglichen eines elektronischen Identitätsnachweises, die sich an den Richtlinien des BSI TR-03110, TR-03112, TR-03130 orientiert, bereit, und zwar in dem Entwicklungszustand, in dem sie sich zum Zeitpunkt der Bereitstellung befindet. Diese Software, die im Folgenden als eIDClientCore bezeichnet wird, hat die Humboldt-Universität von der Bundesdruckerei GmbH, Oranienstraße 91, 10969 Berlin zur Verwendung in Lehre und Forschung sowie zur Bereitstellung an die Öffentlichkeit („Hosten“) für die allgemeine Prüfung und Verwendung durch jedermann erhalten.
15
stars
16
forks
source link
OpenSSL needs to know the RSA-PSK-AES*** cipher suites is TLSv1.2 context #25
I'm not the expert on that TLS stuff, but the findings are as follows.
In case the server disabled the SSLv3 protocol, but allows SSLv3 and TLSv1 cipher suites, the eIDClient can connect while PAOS communication and uses in ClientHello cipher suite RSA-PSK-AES128-CBC-SHA/RSA-PSK-AES256-CBC-SHA, because the cipher suites are known in SSLv3 context.
Due to BEAST and POODLE attack on SSLv3 and CRIME attack on TLS 1.0 the server restricts the cipher suites as well that only cipher suites for TLSv1.1 and TLSv1.2 are allowed.
But now with given RSA-PSK patches on openssl sources, the TLS handshake fails due to "no cipher suite available" (SSLv3 ciphers are disabled)
But it's fact and the official AusweisApp2 is able to connect to the server, while the eIDClientCore TLS handshake fails.
My request is to adjust the RSA-PSK patch that the cipher suites are put into TLSv1.2 context.
I was able to do it partly by changing in ./ssl/s3_lib.c the line "SSL_TLSV1" into "SSL_TLSV1_2" in those two blocks:
/* Cipher 94 */
....
SSL_TLSV1_2,
/* Cipher 95 */
....
SSL_TLSV1_2,
....
An "openssl ciphers 'RSAPSK' -v" command will show now:
RSA-PSK-AES128-CBC-SHA TLSv1.2 Kx=....
RSA-PSK-AES256-CBC-SHA TLSv1.2 Kx=....
But it finally fails during real usage on TLS handshake.
Hopefully someone knows to put the cipher suites into TLSv1.2 context.
Arrgh....
This isssue can be closed as the fault was on Server side.
The eIDclient can now connect to eID Service with the given OpenSSL patch.
There is no need to put the RSA-PSK cipher suites into context of TLSv1.2.
psytester
commented
9 years ago
Long preface:
I'm not the expert on that TLS stuff, but the findings are as follows. In case the server disabled the SSLv3 protocol, but allows SSLv3 and TLSv1 cipher suites, the eIDClient can connect while PAOS communication and uses in ClientHello cipher suite RSA-PSK-AES128-CBC-SHA/RSA-PSK-AES256-CBC-SHA, because the cipher suites are known in SSLv3 context.
Due to BEAST and POODLE attack on SSLv3 and CRIME attack on TLS 1.0 the server restricts the cipher suites as well that only cipher suites for TLSv1.1 and TLSv1.2 are allowed. But now with given RSA-PSK patches on openssl sources, the TLS handshake fails due to "no cipher suite available" (SSLv3 ciphers are disabled)
That questions on stackexchange explains that this may not be the way to secure the server: http://security.stackexchange.com/questions/70832/why-doesnt-the-tls-protocol-work-without-the-sslv3-ciphersuites
But it's fact and the official AusweisApp2 is able to connect to the server, while the eIDClientCore TLS handshake fails.
My request is to adjust the RSA-PSK patch that the cipher suites are put into TLSv1.2 context. I was able to do it partly by changing in ./ssl/s3_lib.c the line "SSL_TLSV1" into "SSL_TLSV1_2" in those two blocks: /* Cipher 94 */ .... SSL_TLSV1_2,
/* Cipher 95 */ .... SSL_TLSV1_2, ....
An "openssl ciphers 'RSAPSK' -v" command will show now: RSA-PSK-AES128-CBC-SHA TLSv1.2 Kx=.... RSA-PSK-AES256-CBC-SHA TLSv1.2 Kx=....
But it finally fails during real usage on TLS handshake. Hopefully someone knows to put the cipher suites into TLSv1.2 context.