E-mail Protection Standards we support as of today

E-mail Protection is all about certifying the senders identity and establishing confidentiality with encryption. Both can be layered in "Transport Security" and "Mail Object Security".

Beside a quick overview of the standards we currently support you can see all benefits and drawbacks of each technology below.

Overview of supported digital signature standards

Digital Signature on mail object layer

Digital signing is done on the mail object itself. Independent of how many MTAs (Mail Transfer Systems) are traversed in the internet and how the traffic will be routed - only the owner of the senders private key can sign the message. This is the highest security level for certifying the senders identity. Known standards are S/MIME or OpenPGP.

OpenPGP

• Technology

Uses an open source standard to sign E-mails with the private PGP key of the sender. The recipient can verify the digital signature of the sender and therefore its identity with his E-mail client.

• Benefits
Instead of the MTA (Mail Transfer System) the actual sender of the E-mail will be verified. The identity of the sender is not spoofable and the mail can not be tampered in transit unnoticed .
• Drawbacks
Not every E-mail client supports OpenPGP standard. Trust hierarchy and verification has to be done manually once. The standard does not scale as good as S/MIME.
• Red Bull Usage

Red Bull offers PGP Signing / OpenPGP Signing for specific senders or recipients upon request for specific business cases. Out preferred technology for E-mail signing is S/MIME. If it is necessary to use OpenPGP / PGP please use the contact form.




S/MIME - RECOMMENDED TECHNOLOGY

• Technology

Uses an enterprise grade standard to sign E-mails with the private S/MIME certificate key of the sender. The recipient can verify the digital signature of the sender and therefore its identity with his E-mail client.

• Benefits
Instead of the MTA (Mail Transfer System) the sender of the E-mail will be verified. The identity of the sender is not spoofable and the mail can not be tampered in transit unnoticed. S/MIME is supported by most fully featured E-mail clients out of the box. In comparison to OpenPGP / PGP the technology scales better due the fact that for trust decision public certification authorities are used.
• Drawbacks
Some Webmail clients do not support S/MIME.
• Red Bull Usage

Red Bull recommends using S/MIME for sending relevant B2B messages as they ensure the senders identity and fraud as well as spoofing attacks can be detected easily. For more information use the contact form.




Overview of supported encryption standards

Whilst "Encryption on Transport Layer" only encrypts the data tunnel from the sending to the 1. receiving MTA (Mail Transfer System) - the "Encryption on mail object layer" encrypts the mail object until the recipients private key decrypts the message.
Red Bull recommends the usage of encryption of E-mails on mail object layer with the S/MIME standard.




Encryption on transport layer



Encryption on mail object layer







Encryption on Transport Layer

Encryption is handled between the first sending and the first receiving MTA (Mail Transfer System). A TLS tunnel that encrypts the SMTP protocol exchange and the mail data is created. The mail object itself is NOT protected. There are 3 variants for the encrypted tunnel that differ in set up complexity and security:






Opportunistic TLS

• Technology

Outbound E-mail traffic: Creates an encrypted TLS Tunnel to the 1. receiving MTA (Mail Transfer System) if the MTA supports it (if SMTP over TLS is supported and a functional certificate is implemented).
Inbound E-mail traffic: If the sending MTA tries to send encrypted via SMTP and a arbitrary certificate is implemented - it will be accepted.

• Benefits
If both MTAs have set up SMTP over TLS and agree on it - all traffic that is sent between the 1. sending and 1. receiving MTA will be encrypted via SMTP over TLS on transport layer. Administrative effort is low - technology scales well - mails do not get lost.
• Drawbacks
If 1 of the 2 MTAs does not support SMTP over TLS or has temporary issues with it the mail traffic is send unencrypted (protocol downgrade). Furthermore E-mail traffic is only encrypted between 1. sending and 1. receiving MTA - if E-mails traverse multiple MTAS - E-mails are not encrypted. E-mail spoofing attacks and Man-in-the-middle are still possible: As there is no certificate check between the MTAs DNS Spoofing / rerouting of traffic and using a self signed certificate can lead to unauthorized systems or persons read and extract E-mail traffic in unencrypted form.
• Red Bull Usage

This is our default technology that we use. We always try to send E-mails via encrypted TLS Tunnel if the receiving MTA supports it - only if he does not support it we sent the mail unencrypted. Furthermore we offer every MTA to send encrypted mails to us. The TLS certificate of our MTA is stated below:

Red Bull main MTAs:
mail10.redbull.com
mail20.redbull.com

If oppurtunistic TLS is not sufficient for secure communication with your enterprise we recommend using Mail Object encryption via S/MIME with us or one of the improved TLS encryption methods (see below).




Forced TLS

• Technology

Outbound E-mail traffic: Forces a TLS tunnel to a specific mail domain (example.com)
Inbound E-mail traffic: If the sending MTA (identified through hostname/IP) tries to send encrypted via SMTP - it will be accepted. Unencrypted mails from same MTA will be dropped.

• Benefits
All traffic that is sent between the 1. sending and 1. receiving MTA (Mail Transfer System) of the specific mail domain (example.com) will be encrypted via SMTP over TLS on transport layer. No unencrypted SMTP traffic can be send to the 1. MTA of the specific domain. Protocol downlevel attacks are not possible.
• Drawbacks
Technology does not scale well - for every destination E-mail domain a specific mail rule has to be created. Mails can get lost when there are temporary issues with SMTP over TLS on the receiving domain MTA side. Furthermore E-mail traffic is only encrypted between 1. sending and 1. receiving MTA. If E-mails traverse multiple MTAs E-mails are not encrypted. E-mail spoofing attacks and Man-in-the-middle are still possible: As there is no certificate check between the MTAs DNS Spoofing / rerouting of traffic and using a self signed certificate can lead to unauthorized systems or persons read and extract E-mail traffic in unencrypted form.
• Red Bull Usage

Red Bull can set up forced TLS with a specific mail domain upon request and review. If forced TLS is needed please use the contact form




Forced TLS with certificate check

• Technology

Outbound E-mail traffic: Forces a TLS tunnel to a specific mail domain (example.com) the digital certificate of the receiving domain MTA will be additionally validated
Inbound E-mail traffic: If the sending MTA tries to send encrypted via SMTP and the certificate is valid - it will be accepted.

• Benefits
All traffic that is sent between the 1. sending and 1. receiving MTA of the specific mail domain (example.com) will be encrypted via SMTP over TLS on transport layer. No unencrypted SMTP traffic can be send to the 1. MTA of the specific domain. Protocol downlevel attacks are not possible. Due certificate check Mail spoofing attacks and Man-in-the-middle are not possible anymore between the 1. sending and 1. receiving MTA.
• Drawbacks
Technology does not scale well - for every destination E-mail domain a specific mail rule has to be created. Mails can get lost when there are temporary issues with SMTP over TLS on the receiving domain MTA side. Mails can get lost if issues with the certificate arise. Furthermore E-mail traffic is only encrypted between 1. sending and 1. receiving MTA - if E-mails traverse multiple MTAS - E-mails are not encrypted.
• Red Bull Usage

Red Bull can set up forced TLS with certificate check for a specific mail domain upon request and review. If forced TLS with certificate check is needed please use the contact form.




Encryption on Mail Object Layer

Encryption is done on the mail object itself. Independent of how many MTAs are traversed in the internet and how the traffic will be routed only the owner of the recipients private key can decrypt the message. This is the highest security level for keeping messages confidential. Known standards are S/MIME or OpenPGP.






OpenPGP

• Technology

Outbound E-mail traffic: Uses an open source standard to encrypt E-mails with the public PGP key of the recipient. The public key has to be retrieved directly from the recipient beforehand and validated.
Inbound E-mail traffic: The encrypted mail object will be decrypted by the private key of the internal recipient.

• Benefits
Instead of the MTA (Mail Transfer System) the sender of the E-mail will be verified. Independent of how many MTAs the mail is traversing the mail object stays securely encrypted until the owner of the recipients private key decrypts it. No protocol downgrade possible, no spoofing possible.
• Drawbacks
Not every mail client supports OpenPGP standard. Trust hierarchy and verification has to be done manually once. Standard does not scale as good as S/MIME.
• Red Bull Usage

Red Bull offers PGP Encryption / OpenPGP Encryption for specific senders or recipients upon request. Out preferred technology for E-mail encryption is S/MIME. If it is necessary to use OpenPGP / PGP please use the contact form.




S/MIME - RECOMMENDED TECHNOLOGY

• Technology

Outbound E-mail traffic: Uses the S/MIME standard to encrypt E-mails with the public S/MIME certificate key of the recipient. The public key has to be retrieved directly from the recipient beforehand and validated.
Inbound E-mail traffic: The encrypted mail object will be decrypted by the private key of the internal recipient.

• Benefits
Instead of the MTA (Mail Transfer System) the sender of the E-mail will be verified. Independent of how many MTAs the mail is traversing the mail object stays securely encrypted until the owner of the recipients private key decrypts it. No protocol downgrade possible, no spoofing possible. S/MIME is supported by most fully featured E-mail clients out of the box. In comparison to OpenPGP / PGP the technology scales better due the fact that for trust decision public certification authorities are used.
• Drawbacks
Some Webmail clients do not support S/MIME.
• Red Bull Usage

Red Bull recommends using S/MIME for confidential messages as they ensure full encryption of the mail object until they are opened with the recipients private key. For more information see here