21–30 of 65 posts
S/MIME also neatly solves the problem.
The problem is not encryption, S/MIME works well enough for that. The problem is you don't have public keys for people you send to. And there's not a reason for many to get the keys. I wish I could say "I'll read your unencrypted email tomorrow" (and delay it from getting to my inbox).
The article clarifies the issues that exist with SMTP encryption nicely. Regarding the issue with certificates for the servers that the MX points to, I disagree with the author. If the MX for example.com points to mail.example.info, it implies that example.com trusting the handling of its mail to mail.example.info, therefore there is no issue with letting mail.example.info present its own certificate. The article als…
Not sure I made that point clearly but I'm not saying that performing validation against the MX target is wrong. However it requires the MX to be authenticated (i.e. signed with DNSSEC), otherwise the attacker can just falsify the MX and have mail delivered to a server for which it has a valid certificate, making validation useless.
Earlier quoted context omitted.
If you can see a DNS request going out and can send a fake response that arrives before the real one, you have enough resources to pull off a MITM.
Yes, but unless you're the ISP that's not going to be possible surely? Mailservers typically don't run over wireless.
If you're already a passive eavesdropper, all you need is the ability the send a DNS response and you're a man-in-the-middle.
In fact (as the article admits), the encryption is fine and fully effective against a passive attacker, the problem is that it's not much use against an active man-in-the-middle. But, that's not something anyone but a NSA or ISP can easily do between mailservers.
The problem is that most of my emails will end up on Gmail, Yahoo! or Hotmail. Since nearly no one uses PGP, the emails sit on a google, apple, yahoo, microsoft server in plain text for any ads or 'gov' company to see and analyze in bulk. Until we 'solve' THIS problem, there's no point in discussing what happens in between IMHO.
It's indeed not a nice situation, I'd love for my mailserver to insert a line into the message subject something like: 'TLS not used' when this is the case (or a plugin for Roundcube (Next?) that colors the subject, how cool would that be?). Just so I know and are aware of suspicious things. Enforcing TLS (and valid certs + strong encryption) is just not very practical yet, although it will definitely not affect mayo…
Earlier quoted context omitted.
The problem is not encryption, S/MIME works well enough for that. The problem is you don't have public keys for people you send to. And there's not a reason for many to get the keys. I wish I could say "I'll read your unencrypted email tomorrow" (and delay it from getting to my inbox).
S/MIME actually solves the key problem pretty nicely, every signed mail contains the certificate that is required to send an encrypted reply. Just start signing your mails.
It's indeed not a nice situation, I'd love for my mailserver to insert a line into the message subject something like: 'TLS not used' when this is the case (or a plugin for Roundcube (Next?) that colors the subject, how cool would that be?). Just so I know and are aware of suspicious things. Enforcing TLS (and valid certs + strong encryption) is just not very practical yet, although it will definitely not affect mayo…
A header would probably be more appropriate. Then any client could display it differently. The problem is that your mail server can only tell that the last leg of the connection was encrypted, not that all connections from the sender's client were all encrypted.
It's indeed not a nice situation, I'd love for my mailserver to insert a line into the message subject something like: 'TLS not used' when this is the case (or a plugin for Roundcube (Next?) that colors the subject, how cool would that be?). Just so I know and are aware of suspicious things. Enforcing TLS (and valid certs + strong encryption) is just not very practical yet, although it will definitely not affect mayo…
This should be pretty easy to do with a SIEVE filter rule: If the Received: line inserted by your mail server doesn't contain "using TLS..." you put a prefix into the mail subject.
This article motivated me to at least create a self-signed certificate for my server.
Why not get a free real certificate form letsencrypt or startssl?
StartSSL limits you to one year and Let's Encrypt is really focused on certificates for HTTPS (their ACME protocol AFAIK requires a handshake through HTTPS).
Earlier quoted context omitted.
The problem is that most of my emails will end up on Gmail, Yahoo! or Hotmail. Since nearly no one uses PGP, the emails sit on a google, apple, yahoo, microsoft server in plain text for any ads or 'gov' company to see and analyze in bulk. Until we 'solve' THIS problem, there's no point in discussing what happens in between IMHO.
Even if you run your own mailserver, you're not in control unless it's a dedicated server. On a VPS you may be spied upon by your ISP without standing a chance of noticing it. Luckily there are now ISPs that let you rent a dedicated server for 6€ a month (or just host it at home on something like the Raspberry Pi 2 and use a minimal VPS just to tunnel the traffic to it from its non-dialup IP address so email actually…