[Ach] SSLyze / GnuTLS

Adi Kriegisch adi at kriegisch.at
Fri Nov 22 08:32:12 CET 2013


Hi!

> So here's some documentation that isn't very helpful, I found:
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html 
> 
> But it points to http://www.gnutls.org/manual/html_node/Priority-Strings.html
Great! This documentation is for GnuTLS3 whereas Debian/stable comes with
GnuTLS2 (2.12.20).
 
> So here's one that I came up with that exim actually starts with:
> 
> tls_require_ciphers =
> NONE:+VERS-TLS-ALL:+MAC-ALL:+RSA:+AES-256-CBC:+AES-128-CBC:+SIGN-RSA-SHA512:+SIGN-RSA-SHA384:+SIGN-RSA-SHA256:+SIGN-RSA-SHA224:+SIGN-RSA-SHA1:+COMP-NULL:-MD5
For which kind of communication? 

> One can test what that would result in with
> 
> $ gnutls-cli --priority "$prioritylist" -l
Hmmm... yeah -- that works fine on GnuTLS3 but doesn't for older versions.
AFAIK there is no way to expand a GnuTLS ciper string in older GnuTLS
versions. Although there are some library functions that might be used to
get exactly that...
 
> That might be broken on wheezy (can somebody confirm?) but on Fedora it sort of
> works. The results for the list above are very minimal:
Compared to the cipher string you gave to it, it looks correct; compare it
(as the string starts with NONE, I just count the '+' parts):

> TLS_RSA_AES_256_CBC_SHA1                            0x00, 0x35  SSL3.0
> TLS_RSA_AES_256_CBC_SHA256                          0x00, 0x3d  TLS1.2
> TLS_RSA_AES_128_CBC_SHA1                            0x00, 0x2f  SSL3.0
> TLS_RSA_AES_128_CBC_SHA256                          0x00, 0x3c  TLS1.2
+AES-256-CBC:
+AES-128-CBC:

> Certificate types: none
> Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0, VERS-SSL3.0, VERS-DTLS1.0
+VERS-TLS-ALL

> Compression: COMP-NULL
+COMP-NULL

> Elliptic curves: none
> PK-signatures: SIGN-RSA-SHA512, SIGN-RSA-SHA384, SIGN-RSA-SHA256,
> SIGN-RSA-SHA224, SIGN-RSA-SHA1
+RSA:
+MAC-ALL:
+SIGN-RSA-SHA512:
+SIGN-RSA-SHA384:
+SIGN-RSA-SHA256:
+SIGN-RSA-SHA224:
+SIGN-RSA-SHA1:

> But my output on wheezy looks different from that, listing MACs and key
> exchange algorithms … Hrmrmrm. Very sceptical.
GnuTLS on Wheezy does not filter because it does not support a version
string. So it shows all it supports.
On Redhat/Fedora elliptic curves were disabled for the past years due to an
unclear legal situation. Only very recently they started enabling ECC in
Fedora.
 
> Funky bits like %SERVER_PRECEDENCE don't seem to work with exim either. It
Hmm... This is only available in GnuTLS3, I guess. Same issue with apache's
mod_gnutls.

> would really help if another tool could enumerate whatever it actually offers.
> I remember some shell script that uses openssl in a really inefficient way to
> list ciphers - given that nothing else worked that might be an option? Pointers
> welcome …
Hehe... openssl is to blame here: IANA lists the official cipher suite
names which gnutls (mostly) uses. Only openssl has its own names. eg.
0x002f
IANA: TLS_RSA_WITH_AES_128_CBC_SHA
GnuTLS: TLS_RSA_AES_128_CBC_SHA1
OpenSSL: AES128-SHA

IMHO the only reasonable resolution is via the IANA list and the hex codes:
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
This table is also available as CSV and XML... So pretty coder friendly.

> > In case you want to help out, would you want to join our meeting next
> > monday?
> I'm not in Vienna at the moment. I'll be back in about a month from now.
Probably we can continue that work over the mailing list, then?! ;-)

-- Adi 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20131122/be506748/attachment.sig>


More information about the Ach mailing list