3 ms·

Certificates for SMTP servers are meaningless without DNSSEC because crossdomain email servers are a thing.

by ryan-c 11y ago

geofft 11y ago
Crossdomain web hosts are also a thing, and HTTPS works fine. (Sometimes with particularly hilarious definitions of "fine", like CloudFlare's former practice of putting dozens of customers' websites in the same certificate, via subject alternative names.) If you're worried about the fact that your mail host and web host can now impersonate each other, we can just define a new X.509 extension for "I can only be used for email". You might even be able to get away adding a new option to the existing Extended Key Usage field, but it's possible that enough clients don't enforce it rigorously enough. Ideally, you'd also want an SMTP equivalent of strict transport security.
- jimktrains2 11y ago
  SMTP can use TLS, though, right? It doesn't _have_ to use STARTTLS? You _could_ use SNI. My concern is that it doesn't get you anywhere. phishing sites can and do get TLS/SSL certificates. The process isn't particularly difficult or labour intensive if you own the domain. As far as spam goes, so what? This only proves I'm talking to the server I intended to, not that it's a reputable and upstanding member of the server society.
  - thetmkay 11y ago
    What about EV itself? Currently there's no EV equivalent for individuals, but it would be a step forward.
    - jimktrains2 11y ago
      If I can't reasonably get it, then how is it a step forward?
      - thetmkay 11y ago
        It would at least help companies/freelancers to host their own mailserver. The same infrastructure may lead to EV for individuals (or equivalent) once we can figure that out. Waiting for everything to be equally ready leads to inaction.
- ryan-c 11y ago
  If someone spoofs a CNAME to evil.com in response to DNS query for google.com, your browser will not accept a certificate from evil.com as valid for google.com, whereas if you send mail to gmail.com and someone spoofs an MX record for mx.evil.com, a vaild mx.evil.com certificate will be accepted.
  - geofft 11y ago
    Right, so "don't do that." There isn't a clear standard for what subject to accept, out of the two options. The obvious correct one is to check for google.com, even if you're talking to a server named mx.google.com -- just as you don't trust CNAMEs and you check the original name, don't trust MXes either. It's just that most people don't have those certs configured in their mail servers, so doing that check today would lead to widespread failures and it's a bad default. Postfix, for instance, lets you configure what it checks via the "smtp_tls_verify_cert_match" option. If you set it to "nexthop", it'll require google.com. The default, "hostname", will check against mx.evil.com. http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_...

Certificates for SMTP servers are meaningless without DNSSEC because crossdomain email servers are a thing.

by ryan-c 11y ago

Certificates for SMTP servers are meaningless without DNSSEC because crossdomain email servers are a thing.

Crossdomain web hosts are also a thing, and HTTPS works fine. (Sometimes with particularly hilarious definitions of "fine", like CloudFlare's former practice of putting dozens of customers' websites in the same certificate, via subject alternative names.) If you're worried about the fact that your mail host and web host can now impersonate each other, we can just define a new X.509 extension for "I can only be used for email". You might even be able to get away adding a new option to the existing Extended Key Usage field, but it's possible that enough clients don't enforce it rigorously enough. Ideally, you'd also want an SMTP equivalent of strict transport security.

jimktrains2 11y ago
SMTP can use TLS, though, right? It doesn't _have_ to use STARTTLS? You _could_ use SNI. My concern is that it doesn't get you anywhere. phishing sites can and do get TLS/SSL certificates. The process isn't particularly difficult or labour intensive if you own the domain. As far as spam goes, so what? This only proves I'm talking to the server I intended to, not that it's a reputable and upstanding member of the server society.
- thetmkay 11y ago
  What about EV itself? Currently there's no EV equivalent for individuals, but it would be a step forward.
  - jimktrains2 11y ago
    If I can't reasonably get it, then how is it a step forward?
    - thetmkay 11y ago
      It would at least help companies/freelancers to host their own mailserver. The same infrastructure may lead to EV for individuals (or equivalent) once we can figure that out. Waiting for everything to be equally ready leads to inaction.
ryan-c 11y ago
If someone spoofs a CNAME to evil.com in response to DNS query for google.com, your browser will not accept a certificate from evil.com as valid for google.com, whereas if you send mail to gmail.com and someone spoofs an MX record for mx.evil.com, a vaild mx.evil.com certificate will be accepted.
- geofft 11y ago
  Right, so "don't do that." There isn't a clear standard for what subject to accept, out of the two options. The obvious correct one is to check for google.com, even if you're talking to a server named mx.google.com -- just as you don't trust CNAMEs and you check the original name, don't trust MXes either. It's just that most people don't have those certs configured in their mail servers, so doing that check today would lead to widespread failures and it's a bad default. Postfix, for instance, lets you configure what it checks via the "smtp_tls_verify_cert_match" option. If you set it to "nexthop", it'll require google.com. The default, "hostname", will check against mx.evil.com. http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_...