The LuxSci FYI Blog

by Erik Kangas, PhD, CEO

Can S/MIME be trusted when SSL has had so many security issues?

Published: March 26th, 2015

SSL and TLS have had a lot of security issues over the past 1-2 years. While these have been patched quickly, they have been very bad and have changed our view of and trust of the Internet. S/MIME is really just aspects of SSL/TLS applied to secure email messages (we looked at this previously). So …. can S/MIME be trusted? Does it suffer from the same vulnerabilities as SSL? Is S/MIME a good thing to use for secure email or should it be avoided with a 10-foot pole?

As we shall see, S/MIME is impervious to the majority the issues with SSL due to the fact that there is no real-time negotiation of cryptographic algorithms and there can be no man-in-the-middle.

Lets see…

Is S/MIME vulnerable to the recent popular SSL issues?

FREAK

The FREAK exploit (reference) works by allowing a man-in-the-middle to alter the cryptographic algorithms negotiated between client and server to be very weak (old export grade) ones so the resulting encrypted communications are easily cracked.

S/MIME is not vulnerable as the sender choose the crypto algorithms used without any real-time negotiation with the recipient. So, there is no opportunity for an attacker to influence which are used.

POODLE

The POODLE attack (reference) sometimes allows an attacker to decrypt a single byte of an SSLv3 protected conversation. Repeating the attack might allow an attacker to decrypt multiple bytes of a secret (for example Session-Cookie, Password…) that is repeatedly sent.

S/MIME is not vulnerable as POODLE requires many different and similar secured messages to be sent and requires that the attacker be a man-in-the-middle who can alter the data stream. This is not possible with S/MIME.

Heartbleed

The Heartbleed attack (reference) allowed attackers to access SSL private keys (very bad). It used a flaw in the real-time negotiation of SSL between client and server to do this.

S/MIME is not vulnerable as there is no negotiation between client and server, and indeed, no server involved that is positioned to divulge S/MIME private keys in this way to an attacker.

The BEAST

The BEAST attack on TLS/SSL (reference) requires that the attacker can choose plain text to be encrypted and can compare the encrypted plain text to the encrypted text (e.g. by attacking from the client’s web browser during the session). It also requires the attacker to be able to analyze the stream of encrypted tcp/ip packets and how they relate to each other.

S/MIME is not vulnerable to this attack because the message is already encrypted and an attacker cannot participate in the encryption process.

CRIME

The CRIME attack (reference) can be used to discover session tokens or other secret information based on the compressed size of HTTP requests that use DEFLATE or gzip. CRIME is a brute force attack that requires analysis of many copies of different encrypted data streams where there is similar information at the beginning (e.g. web session cookies).

S/MIME does support message compression (though it is not necessarily widely used), but it is not vulnerable to this attack as there is only one encrypted content block. Even across multiple captured S/MIME messages, there is little expectation that the beginning of the encrypted message is usefully the same. Additionally, it is unclear if the implementation of compression used by S/MIME is even analyzable in this way.

TIME

The TIME attack (reference) uses timing information to determine the size of compressed, encrypted data. This is not feasible for S/MIME where all of the encryption is performed ahead of time and thus no timing information is available…

S/MIME … not vulnrable.

This is only a subset of recent well-publicized attacks on SSL, but as you can see, S/MIME is not vulnerable to any of them because:

There is no real-time client-server negotiation

There is no opportunity for an attacker to influence the message data stream

There is no opportunity for an attacker to analyze the encryption process

Email differs from web traffic, in that there are not frequent encrypted messages with the same SSL symmetric encryption keys that also have the same or very similar content at the beginning (e.g. HTTP headers and cookies).

Are there vulnerabilities with S/MIME?

S/MIME does have some limitations you should be aware of. These are related to use of old software, to use of old certificates, and to what is actually encrypted by S/MIME:

Headers: S/MIME (and PGP) does not encrypt your email message headers. This means that the To, From, and Subject are not encrypted and are visible for anyone to see as the message is transmitted or stored. The transmission can be further secured by also using SMTP TLS (on top of S/MIME).

Weak Keys: The encryption of S/MIME is only as good as the cryptographic algorithms used and the key sizes used. For example: RSA is commonly used for the S/MIME certificates.

People should be moving to 2048bit RSA keys for S/MIME like they do for SSL/TLS. Older 1024bit keys are weak and smaller ones easily crackable.

If you have an old S/MIME certificate … it may be time to get a new one with a better key.

Old Certificates: S/MIME certificates do not generally expire for a long time (unlike SSL certificates used for web sites)

People are more likely to have and use old certificates that have RSA key sizes that are too small to be very secure.

Compromised keys are more likely to still be valid

Certificate Validity: There is no real certificate revocation system for S/MIME that works and is universal

Compromised keys and old keys could be used and trusted allowing an attacker to access read messages.

Somehow, the sender has to get the compromised/old public key and use it for sending the message and the message has to be delivered to the attacker (or the attacker has to be able to intercept it) for this to be viable. This is much harder with email than with web traffic, but it is possible.

Symmetric Encryption Strength: The cryptographic algorithms used formessage authentication and symmetric encryptionare chosen by the sender’s email system. These could be weak or poorly chosen if the sender is using old software. Whatwas considered strong 10 years ago is not today in many cases.

S/MIME encryption should use strong encryption such as AES-256 and SHA256 and should avoid older and weaker algorithms.