© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
But Debian & Fedora implementation are buggy, because they break 1.0.2x users & they do not prohibit DTLSv1.1 whilst enforcing TLSv1.2+.
So although Debian & Fedora look "nice" they are security vulnerable configurations.
I can set min_version to TLSv1.2, in addition to security level 2 but that will not make current stable test_ssl test suite pass, as it will require not only changing min_level but also setting security level to 1.
I do not see a way to make things secure, for both TLS and DTLS, and discoverable and not pain to use. Because when default context is created it is not known if TLS or DTLS will be used, and the enums for TLS & DTLS are not compatible with each other.
Ultimately it is deficiency in the OpenSSL APIs because it is impossible to know what is or isn't allowed by a given client OpenSSL context, against which server context, and vice versa. Even when enums are available, and one sets them as appropriate min/max. There are no inspection APIs available into the security levels. For example, it impossible to query if ones client certificate is suitable for a given security level, apart from trying to establish the connection.
Re Kurt => i have spoken to Kurt about this, he is aware that Debian's implementation is buggy and he does prefer Ubuntu's one, however Ubuntu's one is not without drawbacks either. I.e. at the moment in Debian people simply choose to not install openssl package and thus end up operating without public certificates and with TLS v1.1/v1.0 enabled, meaning the system is insecure by accident against the intentions. Especially if one tries to be secure, and use private CA certificates only.
"""
2) With some configuration, OpenSSL's SSL_do_handshake() function fails with an "internal error" message (SSL_AD_
"""
I'm not sure how this is related to anything of the above, can you please open a new bug report with details? crashes in handshake are typically specific to the connection type, context on both client & server, and well bugs. The one thing that I know failing badly, is when server has redundant tls certificates in its chain that are considered insecured (i.e. old CA cross-signed new CA). And OpenSSL client currently rejects establishing the connection, despite the server chain having alternative paths of certs that are secure throughout.