Why — After 40 Years — Are We Still Using Unencrypted and Unverified Email?

Why — After 40 Years — Are We Still Using Unencrypted and Unverified Email?

Email was the killer app that made the Internet and which was closely followed by the Web. And so port 25 (SMTP — Simple Mail Transport Protocol) and port 80 (HTTP) built the Internet. But, while the Web has become more secure and trusted (with a move to HTTPs), we still blindly send unsecured and unverified emails. Overall, the use of email it is still the major cause for security weaknesses, as users can easily be tricked into clicking on untrusted links in emails, and in incorrectly replying to emails. Basically there’s almost zero trust in many of our email systems.

To improve security, we thus need to increasingly encrypt email and also digitally sign it. So let’s look at a more secure method of sending an email.

The classic RFC … 822

In 1982, a classic RFC was drafted [here]:

It defined a way to represent header fields in message requests and responses within Internet messages. This scaled to many of the classic protocols, suc as HTTP, SMTP and FTP, and allowed us to create a header for the transmitted data. For email messages, we have the following header fields:

• Bcc: A blind copy recipient address.
• Cc: A carbon copy recipient address.
• Content-Transfer-Encoding: Defines the format of the encoded message.
• Content-Type: The MIME format used.
• Date: The date of the sending of the message.
• From: The sender of the email.
• Subject: The subject field.
• To: The recipient address.

An example is:

From: Bob <[email protected]>
To: Alice <[email protected] >
Date: Sun, 20 Dec 2013
Subject: Test message
Hello Alice.
This is an email to say hello
.

For email, we then needed a way to translate different content types (such as images and video) into a single email message. The answer was MIME (Multipurpose Internet Mail Extension) and which allowed for multiple attachments to be integrated into a single email message.

To send an email we then can use a protocol such as SMTP, and which issues commands which allows the message to be sent to an email exchange. The bold text in the following example represents the sender of the email, and the other text represents the responses of the email exchange:

220 napier Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Sun, 2 Dec 2009 21:56:01 +0000
help
214-This server supports the following commands:
214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY
helo me
250 napier Hello [10.10.75.1]
mail from: [email protected]
250 2.1.0 [email protected] OK
rcpt to: [email protected]
250 2.1.5 [email protected]
Data
354 Start mail input; end with <CRLF>.<CRLF>
From: Bob <[email protected]>
To: Alice <[email protected] >
Date: Sun, 20 Dec 2013
Subject: Test message
Hello Alice.
This is an email to say hello
.
250 2.6.0 <NAPIERMp7lzvxrMVHFb00000001@napier> Queued mail for delivery

S/MIME

With MIME and RFC 822 we have a format for sending and receiving mail. S/MIME (Secure/Multipurpose Internet Mail Extensions) supports the encryption and signing of email messages while keeping compatibility with existing MIME formats. A specified digital certificate is required to read the encrypted email, and where the message is encrypted with the public key of the recipient of the receiver, and decrypted with their private key. A sender can also digitally sign the email message with their private key, and prove their identity with their public key.

In the following, we will send an encrypted email from Bob to Alice. Alice will generate a key pair and then send Bob her public key within an X.509 certificate. Bob then encrypts with Alice’s public key, and Alice decrypts with her private key. If we wanted to sign the email message, we would use Bob’s private key to create a signature, and then Alice would use his public key to verify his identity [here]:

package main

import (
 "crypto"
 "crypto/tls"
 "crypto/x509"
 "crypto/x509/pkix"
 "fmt"
 "os"

"github.com/InfiniteLoopSpace/go_S-MIME/pki"
 "github.com/InfiniteLoopSpace/go_S-MIME/smime"
)

var (
 root = pki.New(pki.IsCA, pki.Subject(pkix.Name{
  CommonName: "root.example.com",
 }))

intermediate = root.Issue(pki.IsCA, pki.Subject(pkix.Name{
  CommonName: "intermediate.example.com",
 }))

leaf = intermediate.Issue(pki.Subject(pkix.Name{
  CommonName: "leaf.example.com",
 }))

AlicekeyPair = tls.Certificate{
  Certificate: [][]byte{leaf.Certificate.Raw, intermediate.Certificate.Raw, root.Certificate.Raw},
  PrivateKey:  leaf.PrivateKey.(crypto.PrivateKey),
 }
)

func main() {

efrom := "Bob"
 eto := "Alice"
 subject := "Subject"
 message := "Message"

argCount := len(os.Args[1:])

if argCount > 0 {
  efrom = os.Args[1]
 }

if argCount > 1 {
  eto = os.Args[2]
 }
 if argCount > 2 {
  subject = os.Args[3]
 }
 if argCount > 3 {
  message = os.Args[4]
 }

mail := "From: " + efrom + "\nTo: " + eto + "\nSubject: " + subject + "\nContent-Type: text/plain\n\n" + message
 SMIME, _ := smime.New()

// Encrypt with Alice's public key
 ciphertext, _ := SMIME.Encrypt([]byte(mail), []*x509.Certificate{leaf.Certificate})

fmt.Printf("SMIME Encrypted:\n%s\n", ciphertext)

// Decrypt with Alice's private key
 SMIME, _ = smime.New(AlicekeyPair)
 plaintext, _ := SMIME.Decrypt(ciphertext)

fmt.Printf("\n== Decrypted (Alice) ==\n%s\n", plaintext)

fmt.Printf("\n== Alice's certificate details ==\n")
 fmt.Printf("Alice's public key method: %s\n", leaf.Certificate.PublicKeyAlgorithm)
 fmt.Printf("Alice's Issuer: %s\n", leaf.Certificate.Issuer)
 fmt.Printf("Alice's Cert Signature: %x\n", leaf.Certificate.Signature)
 fmt.Printf("Alice's Signature Algorithm: %s\n", leaf.Certificate.SignatureAlgorithm)
}

A sample run is [here]:

SMIME Encrypted:
From: bob@home
To: alice@home
Subject: This is the subject
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
 name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIICAgYJKoZIhvcNAQcDoIIB8zCCAe8CAQAxggFJMIIBRQIBADAvMCMxITAfBgNV
BAMTGGludGVybWVkaWF0ZS5leGFtcGxlLmNvbQIINEpcJJjwUfUwCwYJKoZIhvcN
AQEBBIIBAFA12chSEq9TGs2nJ/dmOlu01IZTj4WDLtsWllRuqIxWFR9wlvWABmty
bAZrsehTraQVnNWLIGOZxu5GoPL3fYsyJqOiEOCI8lcrtbLmS+sZlSd/wvYjGNCa
YGnjNHqWQiXyN4dCun6LG34eqVUxOzJRYl+BNv3y8+IRyMFmadOSLc5CSkCkm1ZS
wi9K5m4rHA1hjjC6K7lT/0xxvrOFohE8VdwMj/075ehnbDgrbMzgw7/hWlgtncn0
qv49WZy88Oer1PwauCoa6oMqTdloakiaT8euQNC/B0X+CLU17xlM/Nj/iiEOj3tN
pqfoheQNPl5XZUmq7jhg6GFXGRqwFC8wgZwGCSqGSIb3DQEHATAdBglghkgBZQME
AQIEEO9tjlVDNnLJ7Z1DtdTCDFuAcATmmJAHZYVVBT3V7+gNa3C8MRNqQrzh8h1+
GO3uxUsCCRQn4HFIyIePOV1vUet7AZ6dGgoI0qiy+atw7aBx0Mni1WqoQ4bkHEuz
he33FjhygXBppb5TzxThyWHRPA9bkxHMuR+b7jPE828JL+uqpJg=

cms/protocol: ASN.1 Error — unexpected trailing data

== Decrypted (Alice) ==
From: bob@home
To: alice@home
Subject: This is the subject
Content-Type: text/plain

This is my message

== Alice's certificate details ==
Alice's public key method: RSA
Alice's Issuer: CN=intermediate.example.com
Alice's Cert Signature: 36eb318cbf0f5ee889e827169528654a905ab7c8788629593ac4b1a1f68ebb6ab4ceb56f598f9a373d962e820577e17e3dbd3ec6e31634aa9dc4b950261058fe1e76dad614303426f50ff68fcd224dbaf1e309b0f5ad942a2ae12d988d180993faeb6cabaecfee2cf8b7394162618e6ba58b0e967247990f5c6acd54d69e0868b684cb7241d7d36f895a1aaa9961aab30e0cb919cb62daec0597ac750082bc12c46ed949cbaed8187c817e06a7817ff8550225a6bada2ed6d8e2cbf34949fb33d1c57506db788a12da80d20b194ea3a2a7fe71ca399f42fae1563c4d528154f4d5df56a4fc46ec137f58cf76597841150ebfc1537465afdec49a336fccc97c2b
Alice's Signature Algorithm: SHA256-RSA

If you want to see the running code, try here:

Conclusions

But you might say … “Our email server is secured by a digital certificate. Well, that only secures the transmission of an email. Once it is on the email server, it will be stored in an unencrypted format, and where system administrators could read. These “insiders” could then leak the contents of email messages. It also does not verify the sender of the email.

Also, if there is a data breach on the email server too, all of the contents of the emails will be leaked. With encryption, it will not be possible to discover the contents of emails, as this requires the usage of the receiver’s private key.

At the very least, we need to start to integrate encrypted and verified email into our government systems, and in highly trusted areas such as law and health care, otherwise, in a decade, our digital world will still be faced with spear-phishing attacks and an untrusted email infrastructure.