Everyone is talking about it at the moment: the secret services are reading.
Telekom, GMX and Web.de are taking advantage of the current discussions on the subject and have recently started offering "E-mail made in Germany". A little background: The 3 have decided to encrypt the transport route of the mails, i.e. the communication between GMX, Telekom and Web.de mail server. However, the mail itself is not encrypted, only the connection with which it is transmitted. Although this probably makes it more difficult to read the mail, it does not prevent it, because as long as mails can be tapped directly at the provider's mail server, the transport route can be as highly encrypted as it wants. A normal mail is unencrypted at the provider. A small example from the Exchange world: Outlook transmits a mail to the Exchange server via an encrypted connection, the Exchange server uses the journal function and transmits the mail to a journal mailbox and in turn via an encrypted route (if possible) to the recipient. The evil admin/secret service/boss only needs to read the journal mailbox and can print out the mail and post it on the company notice board. Securing only the transport route makes it more difficult for someone to intercept just one mail between the mail server and the mail server, but it is not completely impossible, precisely because a much more secure method (Perfect forward secrecy) is apparently not used by the big 3. The CCC comments on this similarly skepticalBut be that as it may: The process is not new and Exchange also supports it, so we can also recreate "E-Mail made in Germany" with Exchange and then go one step further. More on this below.
To use SMTP via TLS (SMTPS) we need a certificate, the certificate should of course come from a public CA and not be a self-signed certificate or a certificate issued by your own CA. The name on the certificate must match the EHLO entries of the receiving connectors of your Exchange server. You can get a free certificate here, for example: www.startssl.com
So if you have a receive connector with the EHLO entry "mail.frankysweb.de", then the name for the certificate must also be issued to "Mail.frankysweb.de". The certificate does not have to be a SAN certificate because you can only assign the SMTP protocol to the public certificate. I won't go into the receiving connector in detail here, as the connection between Outlook and Exchange Server is generally encrypted, with Exchange 2013 this is done via HTTPS:
There is therefore no need to use SMTPS here, unless someone wants to offer SMTPS for other clients (other mail clients, applications, etc.). So let's get straight to the disadvantage of TLS: The client normally decides whether TLS is used, unless it is enforced by the Exchange server. Whether TLS is used or not is determined during the session via the SMTP command "STARTTLS", which the client/application must send:
As you can see in the picture above, "applicationserver.frankysweb.local" is currently establishing a connection to the Exchange server. Exchange responds to the EHLO with the available options. Here you can see that STARTTLS is offered, which basically means "I can use TLS if you want". The client must then send the STARTTLS command to secure the connection. This means that most of the configuration work lies with the client and not with the Exchange Server. TLS can be enforced on the Exchange Server for each connector individually, so you could create one connector for insecure connections and one for secure connections:
Set-ReceiveConnector Secure-Connection -RequireTLS $true
Unsecured connections are no longer accepted on a connector with "-RequireTLS $true", so a mail without SMTPS can no longer be delivered.
The same parameter is also available for the send connector, i.e. the path from the Exchange server to the recipient mail server/smart host:
By default, the following settings apply for the send connector: "If TLS is offered by you, then I use it (-IgnoreSTARTTLS = False), if not then I send unsecured (-RequireTLS = False)". This leads directly to the next problem: TLS can be enforced on the send connector, but if the target mail server does not offer TLS, no mail can be sent. For example, I send my mails to Strato and Strato sends my mails to the rest of the world. The Strato server offers TLS:
Here is an excerpt from the log:
You can see that TLS is offered by the target mail server (in this case my smarthost). Exchange then also switches to TLS mode. The mail is therefore transmitted via SMTPS. So this is "e-mail made in Germany"...
Whether the Strato mail server then also uses TLS to send the mails to the actual target server is something I can no longer understand. The smarthost could also forward the mails directly to evil admins/secret services/chiefs.
I hope it is now clear why "e-mail made in Germany" is not the miracle weapon against eavesdroppers. As long as not everyone uses TLS, it will only help a little and in some cases not at all. A normal e-mail is therefore just like a postcard: anyone who gets hold of it can read it! Stephan Cink (many greetings at this point) has written a nice article about this:
http://www.msxfaq.de/signcrypt/enqsignsa.htm
And he even presents a solution: A gateway that encrypts the mail itself and not just the transport route. Such gateways are available from various providers and actually work in essentially the same way:
Exchange sends the mails to the encryption gateway, the gateway takes care of the encryption and delivers the encrypted mail to the recipient. There are various ways in which the gateways handle this. Such gateways eliminate a large number of problems, but not all of them: the mail can still be read by the evil admin/chief because the mail is first encrypted at the gateway, and the mail can still be intercepted unencrypted at the exchange via journaling before it reaches the gateway. To make the postcard comparison: I give my postcard to the letter carrier and he puts it in an envelope and delivers it. As long as I trust the letter carrier, everything is fine.
So there are pros and cons to all of this. If you want to ensure that an email cannot be read by unauthorized third parties, you have to encrypt the email itself. Outlook supports the S/MIME method for this purpose. S/MIME allows end-to-end encryption, i.e. the mail is encrypted with the public key of the certificate and only the owner of the private key can decrypt the mail again. Sounds good, but unfortunately it also has disadvantages. If I want to encrypt an e-mail, I need the recipient's public key. So I have to know the key or I have to request it beforehand. Simply sending an encrypted e-mail does not work. The recipient of the mail must also take good care of their private key, if the key falls into the wrong hands, the encryption is finished, if it is lost, the mails can no longer be viewed. For example, if you carry the certificate and private key around with you on your smartphone... let's not go there.
Nevertheless, I think S/MIME is a good method because it works quite well and is supported by many clients, including smartphones etc. A free certificate for email encryption is also available from StartSSL, among others.
The certificate can then be imported into Outlook
You can now sign emails with the certificate, which will then also transmit the public key to the recipient.
If you receive signed emails, it is best to add the sender directly as a contact in Outlook, Outlook will then save the certificate for the contact and you can send encrypted emails to the contact in future
As soon as you receive an email that has been encrypted with your public key, Outlook will display this accordingly
Incidentally, S/MIME also works on almost all smartphones, here for example on the iPhone
By the way, Sophos UTM Home also includes a gateway for e-mail encryption
So the options are many and varied - you have to decide for yourself which is best for you.