October 23 2014 Thursday
STARTTLS and POODLE is this really an issue?
I got an email from a customer the other day about mitigating POODLE with IBM's Lotus Protector for Mail Security (LPMS). There is a technote for this, 1687838. At the top there is an interesting warning:
I was asked if this was an issue. My response:
Now, in reality I'd most likely leave SSLv3 enabled in my SMTP environment (I'm not talking about clients connecting here like Outlook, Thunderbird, just edge SMTP relay servers). My rationale (to date) here is laid out below:
Scenario 1 : Both SMTP servers can do TLS1.0+
1. I send an email to blah.com
2. My server and the blah.com are both enabled for STARTTLS
3. The negotiate TLS1.0, the delivery transaction is encrypted between the servers and email flows
Scenario 2 : One server can (but is not mandated to) do STARTTLS, the other can't
1. I send an email to blah.com
2. My server sees that blah.com cannot do STARTTLS
3. The email is sent in plain text and the email flows
Scenario 3 : Both servers can do STARTTLS, but one will only do TLS1.0+ and the other will do SSLv3.
1. I send an email to blah.com
2. My server and the blah.com are both enabled for STARTTLS
3. The servers cannot negotiate a protocol, so no encryption takes place
4. The email is sent in plain text and the email flows
Scenario 3 is the interesting one here. You tried to send an email down an encrypted tunnel but you can't. Even though both servers could. Now POODLE is bad an all, but really, if two SMTP servers are trying to send email to one another via an encrypted tunnel and they fail back to plain text to avoid POODLE what good does that do? POODLE is a man-in-the-middle attack vector, and you could argue that you have no idea where your SMTP transaction is going, but that's really all I can come up with for causing "fail back to plain text". It's not like you have your SMTP edge gateway servers sitting in a Starbucks hanging off their public wifi (if you are, then you really should disable SSLv3).
As President Obama used to say about same sex marriage, my thoughts on this are still evolving, but it sure feels like disabling SSLv3 on an SMTP server may lead to some unexpected results.
If your SMTP edge server is Domino, then you may have issues leaving STARTTLS enabled (as outlined by Frank Paolino) until IBM release the multi-protocol fix (which I think maybe in the 9.0+ fix, it's starting to get confusing about what fix is going where). But this goes back to my main point....in Frank's case ProofPoint have disabled SSLv3, so now Frank has to send plain text email to ProofPoint.
So, I'll throw this out to the world in general....what are you doing for STARTTLS?
IMPORTANT: disabling SSLv3 for XMail may cause severe incompatibility problems with other MTAs that do not support TLS 1.x
I was asked if this was an issue. My response:
Now, in reality I'd most likely leave SSLv3 enabled in my SMTP environment (I'm not talking about clients connecting here like Outlook, Thunderbird, just edge SMTP relay servers). My rationale (to date) here is laid out below:
Scenario 1 : Both SMTP servers can do TLS1.0+
1. I send an email to blah.com
2. My server and the blah.com are both enabled for STARTTLS
3. The negotiate TLS1.0, the delivery transaction is encrypted between the servers and email flows
Scenario 2 : One server can (but is not mandated to) do STARTTLS, the other can't
1. I send an email to blah.com
2. My server sees that blah.com cannot do STARTTLS
3. The email is sent in plain text and the email flows
Scenario 3 : Both servers can do STARTTLS, but one will only do TLS1.0+ and the other will do SSLv3.
1. I send an email to blah.com
2. My server and the blah.com are both enabled for STARTTLS
3. The servers cannot negotiate a protocol, so no encryption takes place
4. The email is sent in plain text and the email flows
Scenario 3 is the interesting one here. You tried to send an email down an encrypted tunnel but you can't. Even though both servers could. Now POODLE is bad an all, but really, if two SMTP servers are trying to send email to one another via an encrypted tunnel and they fail back to plain text to avoid POODLE what good does that do? POODLE is a man-in-the-middle attack vector, and you could argue that you have no idea where your SMTP transaction is going, but that's really all I can come up with for causing "fail back to plain text". It's not like you have your SMTP edge gateway servers sitting in a Starbucks hanging off their public wifi (if you are, then you really should disable SSLv3).
As President Obama used to say about same sex marriage, my thoughts on this are still evolving, but it sure feels like disabling SSLv3 on an SMTP server may lead to some unexpected results.
If your SMTP edge server is Domino, then you may have issues leaving STARTTLS enabled (as outlined by Frank Paolino) until IBM release the multi-protocol fix (which I think maybe in the 9.0+ fix, it's starting to get confusing about what fix is going where). But this goes back to my main point....in Frank's case ProofPoint have disabled SSLv3, so now Frank has to send plain text email to ProofPoint.
So, I'll throw this out to the world in general....what are you doing for STARTTLS?
Nothing, sad but true as all our mail is unencrypted SMTP. Domino is not the edge SMTP relay here in any of my configurations (about 5 different clients) but the firewall guys always just shrug when I tell them that they should really activate encryption for mail :o(