-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 27.08.2015 11:41, Secure-Mail User wrote:
i am planning to support SSLv3 and TLSv1.2 on the same Port via SNI. This has backwards-compatibility reasons.
SNI is a TLS extension. It requires TLS version 1.0 or later. https://tools.ietf.org/html/rfc3546#section-3.1
TLS extensions are not supposed to allow for a version rollback: https://tools.ietf.org/html/rfc3546#section-5 If SNI allows for a version rollback on an SSL/TLS library, it should be considered a vulnerability of this library.
As the result, all SSLv3 connections will *not* be redirected by SNI, which should work fine for you.
Using the "sslversion=SSLv3" or "options=NO_SSLv3" directives affect all services. The default and the SNI.
"options=NO_SSLv3" is currently the default. You may change it with "options=-NO_SSLv3".
The "option" option may be specified in individual service sections, and not only as a global default.
I was not able to use e.g. sslversion=SSLv3 for the default host and change to sslversion=TLSv1.2 on the SNI host.
Good. SNI is not supposed to work with SSLv3.
The first sslversion directive read per conf-file seems to be set and may not be changed with later invocations, right?
The RFC only says TLS extension should not allow for version rollback, but it makes sense to disallow any changes of the protocol version.
So I ended up with restricting the SSLv3 / TLSv1.2 via ciphers only. So the default service has SSLv3 ciphers and options=NO_SSLv2, the SNI service hast TLS1.2 ciphers only (thus only accepts TLSv1.2 connections)
[cut]
Are cipher restrictions sufficient to sort out old SSLvX protocols and sort of FORCE TLS1.2 only?
You should be able to restrict the SNI service to only allow a specific TLS version with "options" specified within the SNI service section.
Is it possible to use some SSLvX based negotiations prior to cipher-negotiation on the SNI-TLS1.2 service, because i did not explicitly use sslversion=TLS1.2 directive?
As TLS version 1.0 or higher is required for the SNI extension, you won't get any SSL connections in your SNI sections.
Mike
Wow - great! Thank you so much for this detailed answer Mike!
The "option" option may be specified in individual service sections, and not only as a global default.
You should be able to restrict the SNI service to only allow a specific TLS version with "options" specified within the SNI service section.
Huh! Yes you are right!! It really works that way..
I was testing on ubuntu 14.04 with v5.22 self-build and the v4.53 ubuntu-repo-default. I was totally sure to have tested that. Maybe i have messed up something with the openssl s_client connect parameters or in the stunnel config file. Just tried it on both versions again - works fine, as you said. "options=NO_xxx" is read and works per service section - great!
Again - thank you very much for the help! :-)
Best Regards, Michael
______________________________________________________ powered by Perfect-Privacy.com / Secure-Mail.biz - anonymous and secure internet.