be Smart.
be Secure.
Phone: 800-441-6612

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

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?


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.


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.


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 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.


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 that is not necessarily widely used) is not vulnerable to this attack as there is only one encrypted content block and, 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.


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 this 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:

  1. There is no real-time client-server negotiation
  2. There is no opportunity for an attacker to influence the message data stream
  3. There is no opportunity for an attacker to analyze the encryption process
  4. 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 (like PGP) is a very good tool to use for end-to-end secured email.  It can be used though a Secure email provider or directly in most email programs.

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:

  1. 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).
  2. 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.
    1. 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.
    2. If you have an old S/MIME certificate … it may be time to get a new one with a better key.
  3. Old Certificates: S/MIME certificates do not generally expire for a long time (unlike SSL certificates used for web sites)
    1. People are more likely to have and use old certificates that have RSA key sizes that are too small to be very secure.
    2. Compromised keys are more likely to still be valid
  4. Certificate Validity: There is no real certificate revocation system for S/MIME that works and is universal
    1. Compromised keys and old keys could be used and trusted allowing an attacker to access read messages.
    2. 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.
  5. 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.
    1. S/MIME encryption should use strong encryption such as AES-256 and SHA256 and should avoid older and weaker algorithms.

Leave a Comment

You must be logged in to post a comment.

• Access Anywhere
• Fast and Robust
• Super Secure
• Tons of Features
• Customizable
• Mobile Friendly

Send and receive email from your favorite programs, including:

 Microsoft Outlook
 Mozilla Thunderbird
 Apple Mail
 Windows Mail

... Virtually any program that supports POP, IMAP, or SMTP

Keep your email, contacts, and calendars in sync:

 Apple iPhone and iPad
 Android Devices
 Windows Phone

... Any device with Exchange ActiveSync (EAS) support

Relay your server's mail through LuxSci via smarthost:

• Resolve issues with ISP sending limits and restrictions
• Improve deliverability with better IP reputation and IP masking
• Take advantage of Email Archival and HIPAA Compliance
• Even setup smarthosting from Google Apps!

Free web site hosting with any email account:

• Start with up to 10 web sites and MySQL databases
• DNS services for one domain included
• Tons of features and fully HIPAA capable

LuxSci's focus on security and privacy:

• Read The Case for Email Security
• Read Mitigating Security & Privacy Threats
• Review our Privacy Policy

The most accurate, flexible, and trusted filters in the business:

• Premium protection with Intel Security Saas
• Realtime virus database guards against the latest threats
• Seven-day quarantine lets you put eyes on every filtered email
• Supplement with our Basic Spam Filter for even more features

End-to-end secure email encryption — to anyone, from anyone:

• No setup required — encryption is automatic and easy to use
• Secure outbound email with TLS, PGP, S/MIME, or Escrow
• Free inbound encryption via our SecureSend portal
• Independent of your recipient's level of email security
• Widely compatible and fully HIPAA Compliant

Add an extra layer of security with an SSL Certificate:

• Secure your web site
• Debrand LuxSci WebMail with your own secure domain
• Access secure email services via your own secure domain

Encrypt your service traffic via secure tunnel:

• Add another layer of security to your SSL connections
• WebMail, POP, IMAP, SMTP, web/database access
• SecureForm posts, SecureLine Escrow, SecureSend access
• Restrict your account to VPN access only

Secure long-term message archival:

• Immutable, tamperproof email retention with audit trails
• No system requirements — minimal setup, even less upkeep
• Realtime archival of all inbound and outbound messages
• Works anywhere — even with non-LuxSci email hosting

Free data backups included with all email hosting accounts:

• Automatic backups of all email, WebAides, web/database data
• Seven daily backups and up to four weekly backups
• Unlimited restores included at no additional cost
• Custom backup schedules for dedicated servers

Automate your email management:

• Save messages to specific folders or to LuxSci WebAides
• Advanced text scanning with regular expressions
• Tag messages, alter subject lines, or add custom headers
• Filter by message charset, type, TLS status, DKIM status
• Chain filters together for even more complex actions

• Bulk add and edit users, aliases and more
• Control sharing and access globally or on a granular level
• Delegate user roles through permissions
• Configure account-wide taglines, sending restrictions, and more
• Remotely administer account via SOAP API

Share, collaborate, organize, synchronize:

• Calendars, Contacts, Documents, Notes, Widgets, Workspaces
• Fine-grained access control and security
• Access anywhere via secure web portal or smartphone
• Save over solutions like Microsoft Exchange

Free folder sharing for all email hosting accounts:

• Share mail folders with other users in your account
• Subscribe to only the folders you want to see
• Set read-only or read-write access control
• View all personal and shared folders via unified web interface

Color code and label your email messages:

• Define and assign multiple IMAP keywords to each message
• Filter, search, and sort by tags
• Compatible and synchronizes with any IMAP email client
• Also usable with WebAide entries