5 ms·

STARTTLS Considered Harmful

45 points by vectorbunny 12y ago

leni536 12y ago
a poorly-programmed client would fall back to using the protocol without TLS This is not a protocol vulnerability though. Poorly written programs cause problems with any protocol.
- dspillett 12y ago
  I think the implication is that the design of this protocol makes it much easier to get away with creating bad code, in comparison to the alternative.
hadoukenio 12y ago
> a poorly-programmed client would fall back to using the protocol without TLS That was the whole point of STARTTLS - to allow a way to start a tunnel but be backwards compatible to older clients. The real problem was that they didn't account for MITM attacks.
- gioele 12y ago
  Many applications that support STARTTLS can be configured to require a secure connection to be in place before sending any data.
  - jgillich 12y ago
    Not just applications, servers as well. My Postfix/Dovecot setup does support unencrypted connections, but will refuse to do authentication if the channel is not encrypted.
    - brongondwana 12y ago
      Which is pointless when the plaintext password has already been sent across the wire.
- hobarrera 12y ago
  Since it's just for backwards compatibility, modern clients should never drop to unencrypted communication. It's the server that needs to support older clients, not the other way around.
dtech 12y ago
> To mitigate pervasive monitoring, new protocols should have only secure versions. Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed) For the mentioned protocols: most IMAP and SMTP servers (which enable TLS) disregard the IETF and allow TLS-on-connect connections on ports 993 and 465 respectively. If the IETF would (again) standardize this the problem would be reasonably solved.
- mike-cardwell 12y ago
  My understanding is that in HTTP/2.0 encryption will be optional. But that Chrome and Firefox at least will require it.
- hobarrera 12y ago
  >> Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed) Using ad-hoc certificated is as safe as using STARTTLS: a MITM can just put his own cert (similar to a MITM removing the STARTTLS capability announcement from the client to the server). It's actually worse, since the client will think it's communication is safer than it actually is.
  - Karunamon 12y ago
    This is a matter of UI design, then. Eventually I'd expect secure sites to be the default (with broken lock symbols in the URL bar if not), with higher levels of security carrying something like the secure site symbols we see today. Encryption and identity assurance are two different things - you can easily have the first which makes passive monitoring much more difficult without the trust infrastructure to mitigate MITMing. For the average user, knowing what we know now, I'd say the first is a much more clear and present danger. The second requires a person to actually take interest in your traffic.
gioele 12y ago
I think people do not understand that the statement "you should always and only use encryption" is seriously flawed when it comes to protocols used by millions of applications. If you are starting a new protocol for a wide audience you cannot just say "encryption is required". Which encryption protocol will you require? And will you stick with it forever? Even when it will be broken? So you want a bit of forward compatibility and you add a version identifier to wire protocol the or some other form of negotiation. Well done, now you are opening your self to protocol downgrade attacks. You can try to fight this as much as you want, but will always be back to square one: support for non-updated applications: drop them or support them even thou you know there is a security problem in supporting them? All the non-public SMTP servers I have used in the last years require the use of STARTTLS-enabled connections. So they are dropping old clients, but they can do that because they have a tight control over the "environment" (their students, their employers, etc). Others do not have this luxury.
- infinity0 12y ago
  I think people do understand your caveat, just that other concerns, such as providing actual security, override this. As the article argues, optional encryption does not work. If you have authentication in the first version of your protocol, you can survive downgrade attacks by authenticating the version number.
  - hobarrera 12y ago
    STARTTLS isn't just "optional encryption". For example, my email server will accept any email encrypted or not, but will only allow authentication over a channel if it's encrypted. But encryption is not optional for the latter case. Email clients that attempt to authenticate won't send passwords over unencrypted plain-text connections, so there's no real vulnerability, unless a client is broken.
    - cm2187 12y ago
      Sending the content of the email unencrypted is a pretty big vulnerability. Emails content is almost as sensitive as passwords and one would hope it would be systematically encrypted.
jvdh 12y ago
I am still not convinced by the "encrypt all the SMTP traffic" argument. It adds more encrypted traffic, but these mails are still decrypted on the mail servers to inspect them and then to forward them again. Worse still, most mail servers and programs have no checks whatsoever regarding certificates of other mail servers or clients. As long as it is able to crypt and decrypt, it's acceptable. If you're lucky there is some sensible admin who restricts algorithms. I'm still worried that this adds too much false sense of security as it is right now.
- lmm 12y ago
  There will always be misconfigurations, so we will always need ways to detect and handle them. Encrypting everything everywhere increases the cost of snooping, which is good. It's a long way from perfect, but that shouldn't stop us from making an improvement.
  - jvdh 12y ago
    You are not encrypting everything everywhere. It is putting things in a different envelope for each hop you are doing in the post. Yes, it is secured in transit, but there is no way that you can verify that everything went securely.
    - lmm 12y ago
      Sure. But the point stands: it makes snooping more expensive. Is it perfect? No. Is it better than nothing? Yes.
allegory 12y ago
Considering every damn SMTP server out there that talks STARTTLS actually just accepts any certificate by default including self-signed ones, isn't this entire point moot? It prevents casual attackers watching the wire i.e. network taps but doesn't prevent MITM at all as you can just proxy it with another self signed cert and it goes through. I know this because our SMTP gateway does exactly that, transparently with postfix.
- leni536 12y ago
  Considering every damn SMTP server out there that talks STARTTLS actually just accepts any certificate by default including self-signed ones, isn't this entire point moot? It's not a protocol but an implementation problem.
  - crpatino 12y ago
    STARTTLS is and implementation of SSL/TLS protocol
  - jvdh 12y ago
    Kudos for stating the obvious. Now how do we do something about this?
- agwa 12y ago
  Yes, the point about downgrades is moot when it comes to server-to-server SMTP, since downgrades have to be allowed to be interoperable. The downgrade problem isn't moot with other protocols (like IMAP or client-to-server SMTP) which are virtually always expected to be secure. And the other points, about how STARTTLS adds complexity and prevents protocol-agnostic termination, still apply.
spindritf 12y ago
Port numbers are a limited resource. That's actually a pretty good point and I wish more services used SRV records to determine which host and port to use. HTTP 2.0 was a chance to implement it for HTTP but the effort fizzled out after just a handful of comments in 2007 or so. I also like the idea of squeezing other information into DNS, like certificates, gpg keys, why not HSTS-like information too? Say, a TXT record enforcing ssl, no exceptions (ssl=all). But all this hinges on DNSSEC which is very unpopular here.
- droopyEyelids 12y ago
  One reason DNSSEC is unpopular is that it fails to address the fact that centralized PKI suffers from tons of problems. Those problems would defeat the purpose of a gesture as serious as putting your gpg key in DNS.
  - spindritf 12y ago
    Sure but those are the same problems that a centralized domain name system suffers from. Currently, we have the privilege of paying for a second centralized system (CAs) which solves none of them.
  - throaway8972 12y ago
    I think it's unpopular, because it is complex and it doesn't address privacy (between you and your ISP at least). Centralized, hierarchical PKI is ok here, because it is better than what we have now (600 CAs for TLS, unsigned DNS, etc.) and nobody has a proposal for a fully decentralized system that ordinary people can understand (as demonstrated by GPG).
  - oconnore 12y ago
    It always seems ridiculous to me that people are coming up with ways to cope with universal CAs (Tack, Convergence, CRLSets, etc.), but can't imagine how to apply those same ideas with a hierarchical system. CAs are a problem that DNSSEC doesn't solve, but DNSSEC solves tons of other problems without making the CA problem harder.
- 12y ago
mcguire 12y ago
"Although it's trivial for a properly-programmed client to protect against this downgrade attack,..." ...that defeats the "use TLS when available" argument.
brongondwana 12y ago
We wrote pretty much this years ago at FastMail: https://www.fastmail.fm/help/technical/ssltlsstarttls.html https://www.fastmail.fm/help/technical/ssltlsstarttls.html All the downgrade and pre-encryption MITM and complexity arguments are definitely worth repeating though. Straight up SSL is significantly better.
inopinatus 12y ago
Opportunistic encryption between endpoints doesn't necessarily require STARTTLS. That is merely a current convention. It could change in future, with the development or invention of some new crypto paradigm. Case in point: opportunistic IPSEC. Okay that wasn't the answer either, but it is an alternative in principle, albeit not in practice today for global SMTP. Point is, I think it's naive and unwise to assume that the crypto upgrade/wrapper is and always shall be TLS and then to build this assumption into standards in a manner that isn't future compatible. We are due a great many innovations in end-to-end crypto over the next few decades. For example, I'm hoping that new and interesting uses will be found for DANE. Maybe we can even bring back network-layer opportunistic encryption.

45 points by vectorbunny 12y ago

a poorly-programmed client would fall back to using the protocol without TLS This is not a protocol vulnerability though. Poorly written programs cause problems with any protocol.

dspillett 12y ago
I think the implication is that the design of this protocol makes it much easier to get away with creating bad code, in comparison to the alternative.

hadoukenio 12y ago

> a poorly-programmed client would fall back to using the protocol without TLS That was the whole point of STARTTLS - to allow a way to start a tunnel but be backwards compatible to older clients. The real problem was that they didn't account for MITM attacks.

gioele 12y ago
Many applications that support STARTTLS can be configured to require a secure connection to be in place before sending any data.
- jgillich 12y ago
  Not just applications, servers as well. My Postfix/Dovecot setup does support unencrypted connections, but will refuse to do authentication if the channel is not encrypted.
  - brongondwana 12y ago
    Which is pointless when the plaintext password has already been sent across the wire.
hobarrera 12y ago
Since it's just for backwards compatibility, modern clients should never drop to unencrypted communication. It's the server that needs to support older clients, not the other way around.

dtech 12y ago

> To mitigate pervasive monitoring, new protocols should have only secure versions. Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed) For the mentioned protocols: most IMAP and SMTP servers (which enable TLS) disregard the IETF and allow TLS-on-connect connections on ports 993 and 465 respectively. If the IETF would (again) standardize this the problem would be reasonably solved.

mike-cardwell 12y ago
My understanding is that in HTTP/2.0 encryption will be optional. But that Chrome and Firefox at least will require it.
hobarrera 12y ago
>> Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed) Using ad-hoc certificated is as safe as using STARTTLS: a MITM can just put his own cert (similar to a MITM removing the STARTTLS capability announcement from the client to the server). It's actually worse, since the client will think it's communication is safer than it actually is.
- Karunamon 12y ago
  This is a matter of UI design, then. Eventually I'd expect secure sites to be the default (with broken lock symbols in the URL bar if not), with higher levels of security carrying something like the secure site symbols we see today. Encryption and identity assurance are two different things - you can easily have the first which makes passive monitoring much more difficult without the trust infrastructure to mitigate MITMing. For the average user, knowing what we know now, I'd say the first is a much more clear and present danger. The second requires a person to actually take interest in your traffic.

gioele 12y ago

I think people do not understand that the statement "you should always and only use encryption" is seriously flawed when it comes to protocols used by millions of applications. If you are starting a new protocol for a wide audience you cannot just say "encryption is required". Which encryption protocol will you require? And will you stick with it forever? Even when it will be broken? So you want a bit of forward compatibility and you add a version identifier to wire protocol the or some other form of negotiation. Well done, now you are opening your self to protocol downgrade attacks. You can try to fight this as much as you want, but will always be back to square one: support for non-updated applications: drop them or support them even thou you know there is a security problem in supporting them? All the non-public SMTP servers I have used in the last years require the use of STARTTLS-enabled connections. So they are dropping old clients, but they can do that because they have a tight control over the "environment" (their students, their employers, etc). Others do not have this luxury.

infinity0 12y ago
I think people do understand your caveat, just that other concerns, such as providing actual security, override this. As the article argues, optional encryption does not work. If you have authentication in the first version of your protocol, you can survive downgrade attacks by authenticating the version number.
- hobarrera 12y ago
  STARTTLS isn't just "optional encryption". For example, my email server will accept any email encrypted or not, but will only allow authentication over a channel if it's encrypted. But encryption is not optional for the latter case. Email clients that attempt to authenticate won't send passwords over unencrypted plain-text connections, so there's no real vulnerability, unless a client is broken.
  - cm2187 12y ago
    Sending the content of the email unencrypted is a pretty big vulnerability. Emails content is almost as sensitive as passwords and one would hope it would be systematically encrypted.

jvdh 12y ago

I am still not convinced by the "encrypt all the SMTP traffic" argument. It adds more encrypted traffic, but these mails are still decrypted on the mail servers to inspect them and then to forward them again. Worse still, most mail servers and programs have no checks whatsoever regarding certificates of other mail servers or clients. As long as it is able to crypt and decrypt, it's acceptable. If you're lucky there is some sensible admin who restricts algorithms. I'm still worried that this adds too much false sense of security as it is right now.

lmm 12y ago
There will always be misconfigurations, so we will always need ways to detect and handle them. Encrypting everything everywhere increases the cost of snooping, which is good. It's a long way from perfect, but that shouldn't stop us from making an improvement.
- jvdh 12y ago
  You are not encrypting everything everywhere. It is putting things in a different envelope for each hop you are doing in the post. Yes, it is secured in transit, but there is no way that you can verify that everything went securely.
  - lmm 12y ago
    Sure. But the point stands: it makes snooping more expensive. Is it perfect? No. Is it better than nothing? Yes.

allegory 12y ago

Considering every damn SMTP server out there that talks STARTTLS actually just accepts any certificate by default including self-signed ones, isn't this entire point moot? It prevents casual attackers watching the wire i.e. network taps but doesn't prevent MITM at all as you can just proxy it with another self signed cert and it goes through. I know this because our SMTP gateway does exactly that, transparently with postfix.

leni536 12y ago
Considering every damn SMTP server out there that talks STARTTLS actually just accepts any certificate by default including self-signed ones, isn't this entire point moot? It's not a protocol but an implementation problem.
- crpatino 12y ago
  STARTTLS is and implementation of SSL/TLS protocol
- jvdh 12y ago
  Kudos for stating the obvious. Now how do we do something about this?
agwa 12y ago
Yes, the point about downgrades is moot when it comes to server-to-server SMTP, since downgrades have to be allowed to be interoperable. The downgrade problem isn't moot with other protocols (like IMAP or client-to-server SMTP) which are virtually always expected to be secure. And the other points, about how STARTTLS adds complexity and prevents protocol-agnostic termination, still apply.

spindritf 12y ago

Port numbers are a limited resource. That's actually a pretty good point and I wish more services used SRV records to determine which host and port to use. HTTP 2.0 was a chance to implement it for HTTP but the effort fizzled out after just a handful of comments in 2007 or so. I also like the idea of squeezing other information into DNS, like certificates, gpg keys, why not HSTS-like information too? Say, a TXT record enforcing ssl, no exceptions (ssl=all). But all this hinges on DNSSEC which is very unpopular here.

droopyEyelids 12y ago
One reason DNSSEC is unpopular is that it fails to address the fact that centralized PKI suffers from tons of problems. Those problems would defeat the purpose of a gesture as serious as putting your gpg key in DNS.
- spindritf 12y ago
  Sure but those are the same problems that a centralized domain name system suffers from. Currently, we have the privilege of paying for a second centralized system (CAs) which solves none of them.
- throaway8972 12y ago
  I think it's unpopular, because it is complex and it doesn't address privacy (between you and your ISP at least). Centralized, hierarchical PKI is ok here, because it is better than what we have now (600 CAs for TLS, unsigned DNS, etc.) and nobody has a proposal for a fully decentralized system that ordinary people can understand (as demonstrated by GPG).
- oconnore 12y ago
  It always seems ridiculous to me that people are coming up with ways to cope with universal CAs (Tack, Convergence, CRLSets, etc.), but can't imagine how to apply those same ideas with a hierarchical system. CAs are a problem that DNSSEC doesn't solve, but DNSSEC solves tons of other problems without making the CA problem harder.
12y ago

mcguire 12y ago

"Although it's trivial for a properly-programmed client to protect against this downgrade attack,..." ...that defeats the "use TLS when available" argument.

brongondwana 12y ago

We wrote pretty much this years ago at FastMail: https://www.fastmail.fm/help/technical/ssltlsstarttls.html https://www.fastmail.fm/help/technical/ssltlsstarttls.html All the downgrade and pre-encryption MITM and complexity arguments are definitely worth repeating though. Straight up SSL is significantly better.

inopinatus 12y ago

Opportunistic encryption between endpoints doesn't necessarily require STARTTLS. That is merely a current convention. It could change in future, with the development or invention of some new crypto paradigm. Case in point: opportunistic IPSEC. Okay that wasn't the answer either, but it is an alternative in principle, albeit not in practice today for global SMTP. Point is, I think it's naive and unwise to assume that the crypto upgrade/wrapper is and always shall be TLS and then to build this assumption into standards in a manner that isn't future compatible. We are due a great many innovations in end-to-end crypto over the next few decades. For example, I'm hoping that new and interesting uses will be found for DANE. Maybe we can even bring back network-layer opportunistic encryption.