3 ms·

We found more than 40 vulnerabilities in STARTTLS implementations. In other words, the bugs are in faulty implementations, not specification. Incidentally I w

We found more than 40 vulnerabilities in STARTTLS implementations. In other words, the bugs are in faulty implementations, not specification. Incidentally I was just reading about STARTTLS recently (i.e. within a month), and having to implement it, looked at the discussions about command injection, whereupon my first reaction was "seriously?" This works by attaching additional commands to the TCP packet that sends the still unprotected STARTTLS command. Am I the only one who thinks it should be bloody obvious that the first byte after the "\r\n" that ends the STARTTLS command should be the first byte of a TLS handshake, and that anyone who uses the term "TCP packet" needs to learn more about how TCP works? Read bytes from the network into a buffer. At each \r\n (or \n to be more permissive), stop and parse the command. If it's STARTTLS, whatever is left in the buffer is the start of the handshake so feed that into the TLS layer. In my implementation, if I wanted to deliberately make it vulnerable, I'd have to make it more complex --- set a flag to remember, and do the TLS handshake only after parsing the whole buffer; but then, as everyone should know, TCP is a stream, so what if the buffer has a partial command in it? No. The only thing that makes sense is the bytes after STARTTLS\r\n are a TLS handshake, and maybe application data if the buffer is big enough. Reading the linked Postfix article about how its design made it vulnerable confirms my suspicions --- they didn't understand TCP.

jsiepkes 2y ago
> In other words, the bugs are in faulty implementations, not specification. Problems with STARTTLS have been going on for atleast a decade. At some point you need to start wondering if the design isn't the problem. Besides, why would you even want STARTTLS? Even the authors of the RFC can't come up with a good reason to use STARTTLS [1]. Most of these reasons are from another era: > Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. Actually knowing in advance if something is going to be a secure connection (like HTTP vs HTTPS) sounds pretty desirable to me. > Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Export ciphers are obviously not a thing in 2024 anymore. And "using a SASL mechanism which includes a security layer" where apparently someone made their own alternative to TLS sounds like a really bad idea. > Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. That actually sounds desirable. > Port numbers are a limited resource. While they are not yet in short supply Only very few protocols get an actual IANA assigned port number nowadays. [1] https://datatracker.ietf.org/doc/html/rfc2595#section-7 https://datatracker.ietf.org/doc/html/rfc2595#section-7

jsiepkes 2y ago

> In other words, the bugs are in faulty implementations, not specification. Problems with STARTTLS have been going on for atleast a decade. At some point you need to start wondering if the design isn't the problem. Besides, why would you even want STARTTLS? Even the authors of the RFC can't come up with a good reason to use STARTTLS [1]. Most of these reasons are from another era: > Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. Actually knowing in advance if something is going to be a secure connection (like HTTP vs HTTPS) sounds pretty desirable to me. > Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Export ciphers are obviously not a thing in 2024 anymore. And "using a SASL mechanism which includes a security layer" where apparently someone made their own alternative to TLS sounds like a really bad idea. > Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. That actually sounds desirable. > Port numbers are a limited resource. While they are not yet in short supply Only very few protocols get an actual IANA assigned port number nowadays. [1] https://datatracker.ietf.org/doc/html/rfc2595#section-7 https://datatracker.ietf.org/doc/html/rfc2595#section-7