5 ms·

It's been a few years since I did server e-mail management, but SMTP/email in 2018 is quite different from SMTP/email in 1985. For starters all large e-mail ex

by dtech 8y ago

It's been a few years since I did server e-mail management, but SMTP/email in 2018 is quite different from SMTP/email in 1985. For starters all large e-mail exchanges (Gmail/Live) require you to use TLS, so most mx<>mx connections are already secured. Additional protocols like SPF, DKIM and DMARC are securing origins, messages and reducing spam and spoofing.

cm2187 8y ago
Yeah but TLS is using STATTLS which is trivially downgradable, most smtp servers on the internet use invalid (selfsigned or expired) certs, and no one validates anything. As for spf, dkim, they are nice hints for spam level but are not used to block spoofed traffic. So all these features are a thin layer in of lipstick on the pig and don’t really make the problem a solved problem.
- dtech 8y ago
  Not blocked, but in Gmail at least you get a nice big red warning if the SPF or DKIM does not match up.
  - tambourine_man 8y ago
    Not only that, I’ve had email outright bounce without those two.
- jacobr1 8y ago
  DMARC failures are blocked at most providers at this point.
- tialaramex 8y ago
  Baby steps. Even with invalid certificates and fairly weak crypto TLS protects us against passive eavesdroppers, which is not nothing. In 1998 if I had a fibre tap for a big backbone carrier, and a line speed regex engine, I could pull matching text out of basically everything travelling over that carrier, silently and with just my small box maybe labelled "Lawful intercept capability" in one corner of one cage in one data centre. Today that doesn't get me much, because it's encrypted. Even if it's encrypted using 3DES and RSA with a self-signed certificate for localhost, I can't read it, and I certainly can't parse it at line speed and run it through my regular expression system to keep the juicy bits, so even if I can decrypt some of that later I'll need to keep it all somewhere until I get that chance. Ugh. So now an adversary has become _active_ and that changes the nature of the game, because while I can't detect passive eavesdroppers (except with "Quantum encryption" which is a fun lab toy but not a realistic component of everyday communications) I can detect active ones. Not everybody cares if they're detected. I doubt Chinese or Russian intelligence agencies are much bothered that journalists visiting know they're bugged, if anything it just helps intimidate them. But if (like the afore-mentioned NSA, or Mossad) your country depends upon the pretence that it is above such shenanigans it sure is embarrassing to keep getting caught... and it also makes it much harder to pretend that everybody defending is just being paranoid. https://starttls-everywhere.org/about/ https://starttls-everywhere.org/about/ is some next steps
- ocdtrekkie 8y ago
  We've seen so many issues with certificate authorities, that validating ownership of certificates based on that system is completely pointless if you're looking for trust. Like, remember Trustico, the guys who emailed 20,000 of their customer's private keys? They're both still in business, and working with one of the largest registrars: https://www.trustico.com/ https://www.trustico.com/
  - tialaramex 8y ago
    Note that Trustico isn't a CA, just a reseller. Also it is much easier to avoid having your reseller (or your CA, or the guy who cleans your pool) email out your private key if you pick your own key and you know, keep it private, rather than letting them choose it and just hoping they deleted their copy. I actually think we've been doing a fairly good job of cleaning up the Web PKI in recent years and I note that other trusted institutions like major banks and newspapers haven't got spotless records either.
    - ocdtrekkie 8y ago
      Trustico is "just" a reseller, but one working with Comodo, an extremely trusted CA. Which calls a lot into question: If we can't trust Trustico (we can't), but they're able to issue Comodo certs, we really can't trust Comodo either. (Beyond the fact that really, if Comodo is still willing to work with Trustico, it's clear Comodo is also not a trustworthy entity.) And even if you or I don't trust Comodo, our web browsers do, because Google and Mozilla have decided Comodo is trustworthy. I don't understand how anyone can suggest that web PKI isn't totally broken as long as this remains the case. And banks don't have perfect records, but I'm not being forced to use a bank. If Google wants to use it's monopoly to force us all to use PKI, maybe it should fix PKI first.
      - tialaramex 8y ago
        > If we can't trust Trustico (we can't), but they're able to issue Comodo certs, we really can't trust Comodo either. I can't fault this logic, which is why I'm happy to tell you that this isn't how resellers work and hasn't been for many years. They can't "issue Comodo certs", they're just a middleman taking a cut. A reseller isn't trusted by the CA at all in Web PKI terms. They handle some customer service stuff and (like an airline discounter) they allow the headline prices to stay high so that the "real" prices seem cheaper. You don't need to trust Trustico at all, as a Relying Party you're depending on Comodo to do their job, independent of Trustico. If you are a Trustico customer, you needn't trust them beyond the fact that you'll be sending them money, and of course any outfit might take the money and run. If you're very naive and you allow Trustico to have your private key (an arrangement Comodo told them to stop when it signed them up as a reseller) then they have your private key. So, never do that, not with Trustico, not with Comodo, not with anybody. The entire point of a private key is that it's private, we can't make it any clearer than that.
- tptacek 8y ago
  There's an SMTP-STS protocol in the works to establish persistent secure relationships between MTAs, which should alleviate a lot of the STARTTLS downgrade pain. Last I checked, most of the major email providers were backing it.

by dtech 8y ago

cm2187 8y ago

Yeah but TLS is using STATTLS which is trivially downgradable, most smtp servers on the internet use invalid (selfsigned or expired) certs, and no one validates anything. As for spf, dkim, they are nice hints for spam level but are not used to block spoofed traffic. So all these features are a thin layer in of lipstick on the pig and don’t really make the problem a solved problem.

dtech 8y ago
Not blocked, but in Gmail at least you get a nice big red warning if the SPF or DKIM does not match up.
- tambourine_man 8y ago
  Not only that, I’ve had email outright bounce without those two.
jacobr1 8y ago
DMARC failures are blocked at most providers at this point.
tialaramex 8y ago
Baby steps. Even with invalid certificates and fairly weak crypto TLS protects us against passive eavesdroppers, which is not nothing. In 1998 if I had a fibre tap for a big backbone carrier, and a line speed regex engine, I could pull matching text out of basically everything travelling over that carrier, silently and with just my small box maybe labelled "Lawful intercept capability" in one corner of one cage in one data centre. Today that doesn't get me much, because it's encrypted. Even if it's encrypted using 3DES and RSA with a self-signed certificate for localhost, I can't read it, and I certainly can't parse it at line speed and run it through my regular expression system to keep the juicy bits, so even if I can decrypt some of that later I'll need to keep it all somewhere until I get that chance. Ugh. So now an adversary has become _active_ and that changes the nature of the game, because while I can't detect passive eavesdroppers (except with "Quantum encryption" which is a fun lab toy but not a realistic component of everyday communications) I can detect active ones. Not everybody cares if they're detected. I doubt Chinese or Russian intelligence agencies are much bothered that journalists visiting know they're bugged, if anything it just helps intimidate them. But if (like the afore-mentioned NSA, or Mossad) your country depends upon the pretence that it is above such shenanigans it sure is embarrassing to keep getting caught... and it also makes it much harder to pretend that everybody defending is just being paranoid. https://starttls-everywhere.org/about/ https://starttls-everywhere.org/about/ is some next steps
ocdtrekkie 8y ago
We've seen so many issues with certificate authorities, that validating ownership of certificates based on that system is completely pointless if you're looking for trust. Like, remember Trustico, the guys who emailed 20,000 of their customer's private keys? They're both still in business, and working with one of the largest registrars: https://www.trustico.com/ https://www.trustico.com/
- tialaramex 8y ago
  Note that Trustico isn't a CA, just a reseller. Also it is much easier to avoid having your reseller (or your CA, or the guy who cleans your pool) email out your private key if you pick your own key and you know, keep it private, rather than letting them choose it and just hoping they deleted their copy. I actually think we've been doing a fairly good job of cleaning up the Web PKI in recent years and I note that other trusted institutions like major banks and newspapers haven't got spotless records either.
  - ocdtrekkie 8y ago
    Trustico is "just" a reseller, but one working with Comodo, an extremely trusted CA. Which calls a lot into question: If we can't trust Trustico (we can't), but they're able to issue Comodo certs, we really can't trust Comodo either. (Beyond the fact that really, if Comodo is still willing to work with Trustico, it's clear Comodo is also not a trustworthy entity.) And even if you or I don't trust Comodo, our web browsers do, because Google and Mozilla have decided Comodo is trustworthy. I don't understand how anyone can suggest that web PKI isn't totally broken as long as this remains the case. And banks don't have perfect records, but I'm not being forced to use a bank. If Google wants to use it's monopoly to force us all to use PKI, maybe it should fix PKI first.
    - tialaramex 8y ago
      > If we can't trust Trustico (we can't), but they're able to issue Comodo certs, we really can't trust Comodo either. I can't fault this logic, which is why I'm happy to tell you that this isn't how resellers work and hasn't been for many years. They can't "issue Comodo certs", they're just a middleman taking a cut. A reseller isn't trusted by the CA at all in Web PKI terms. They handle some customer service stuff and (like an airline discounter) they allow the headline prices to stay high so that the "real" prices seem cheaper. You don't need to trust Trustico at all, as a Relying Party you're depending on Comodo to do their job, independent of Trustico. If you are a Trustico customer, you needn't trust them beyond the fact that you'll be sending them money, and of course any outfit might take the money and run. If you're very naive and you allow Trustico to have your private key (an arrangement Comodo told them to stop when it signed them up as a reseller) then they have your private key. So, never do that, not with Trustico, not with Comodo, not with anybody. The entire point of a private key is that it's private, we can't make it any clearer than that.
tptacek 8y ago
There's an SMTP-STS protocol in the works to establish persistent secure relationships between MTAs, which should alleviate a lot of the STARTTLS downgrade pain. Last I checked, most of the major email providers were backing it.