[EN]
[DE]
Consulting djbware Publikationen
≡  

SMTP and Transport Layer Security (TLS) [Tutorial]

 

2022-01-09 - 4th revision

Chapter 1: Introduction

Chapter 2: Cryptographic Ingredients

Chapter 3: Origin and Scope of the TLS Protocol

Chapter 4: TLS Protocol and Companions: Request for Comments

Chapter 5: Transport Layer Security Framework

Chapter 6: X.509 Certificates

Chapter 7: TLS Applications

Chapter 8: Lose ends upon TLS cryptography

Chapter 1: Introduction

According to our current understanding, all communication over the Internet shall be confidential - using encryption. In order to follow this paradigm, a significant amount of solutions are available; providing this service on different communication layers, as shown in figure 1.

Figure 1: Encryption technologies on different network layers

All of this services using cryptographic primitives though often in different flavors. Protocols like SSH, IPSec, PGP, and SSL/TLS were initially developed and published between 1990 and 1996 making use of the cryptographic primivites available at that time. In particular, the idea of Public Key Infrastructure (eXchange) PKIX was already been born and poured into X.509 certificates.

By construction, neither the MTA protocol SMTP nor the MDA protocols POP3 and/or IMAP4 provide this level of care and are simple 'plain' transport protocols. Without authentication SMTP is not even aware of an authenticated email originator.

In order to achiev confidentially, two different approaches are generally used:

Encryption with [S/MIME, PGP] can only be achived in case the originator as has access to the public key of the recipient which is on a large scale still difficult and only solved (to my oppion) in the PGP Pretty Good Privacy case.

Transport Layer Security TLS however, may work on both, the MTA and MDA level. It does not require any action from the user except from perhaps enabling the check-button 'use TLS encryption'. On the other side, the level of protection/confidentially/encryption is not easily visible for the communicating partners.

TLS touches the SMTP protocol significant - as SMTP Authentication does. Apart from it's transport layer encryption, TLS can be additional used for the following purposes:

Chapter 2: Cryptographic Ingredients

In IT security text-books and publications mostly the so-called 'magical triangle' of IT security is used to describe the (CIA) aimes, given by

Given our today's understanding of IT security, the authentication of data source, and the authorization to receive data and use them are almost as import as the CIA aims. This can be combined together in a CAR scheme of modern IT security (figure 2):

While the first aims are matter of cryptographic engineering, the last two belong to the field of software and systems engineering. Here, we should consider, that in the near future we will depend on autonomous systems (like cars!) where those merits are indispensible.

Figure 2: Magical Triangles of IT Security - from CIA to CAR

This is mainly because cryptography has developed further and modern crypto primitives do a much better job; if applied correctly. In particular the idea to consider bits in a byte as polynomial coefficients

k*x7 + k*x6 + k*x5 + k*x4 + k*x3 + k*x2 + k*x1 + k*x0

(k being either '0' or '1') paved the road not only to a superior understanding how to improve transmission and security of the described data, but also to a faster handling of data by computers using advanced methods, employing finite fields algorithmic. Without this breakthrough neither high speed networking nor 4k satellite TV would be feasible.

Figure 3: The main cryptographic achievements and milestone since 1970. I need to apologize Alan Turing for mirroring his face to look into the future.

Figure 3 gives an overview what happend in the field of cryptography since 1970:

Below the timeline some import implementation breakthroughs are mentioned. We expect additional important cryptographic achievements followinng the NIST Post Quantum Cryptography Challenge. The New Hope algorithm is now part of CRYSTAL with strong competition from NTRU, where Daniel Bernstein is involved. Both are are Lattice based mechanisms using Galois fields using the above mentioned presentation of bits.

We can breakdown every modern IT security protocol to use four cryptographic primitives:

  1. Symmetrical encryption empying the same key and the same functions for en- and decryption.
  2. Hash functions using roughly the same math as symmetrical block encryption, but how serve as none-injective functions.
  3. Key Exchange functions employing trapdor math implementations, allowing either a key encryption method KEM or a key exchange method KXM.
  4. Signature functions allowing to sign data, thus the origin and authencity can be guaranteeed (signing and verification).

Figure 4: The four crypto primitives sketcheds as XKCD comic while employing Alice and Bob, Luke Skywalker, the Emporer, and Darth Vader.

The last two methods belong to the asymmetrical or public/private key regime employing different implementation in either direction. We expect 'symmetrical' crypto to be stand Quantum computers while all asymmetrical methods need to be re-implemented. This task is currently onging.

In any case, Bob and Alice previous of applying any possible method they need to agree upon the chosen primitives. This is a cleartext attribute to be exchanged, called the Cipher Suite. Now they can start to exchange a common secret. Given asymmetrical cryptography, this is simply a large number only, not known except for both of them. From this number (and additional public material) all other keys required in later steps are derived. A bit scaring though ;-)

Chapter 3: Origin and Scope of the TLS Protocol

Our current TLS protocol is the successor of the former SSL Secure Socket Layer protocol, whose implementation was mainly written by Eric A. Young for Netscape named SSLeay back in 1994.

At that time, cryptographers developed hybride encryption techniques based on

  1. Asymmetric Public Key/Private Key encryption like Diffie-Hellman and RSA to allow the exchange/secret agreement on a
  2. shared secret key for fast symmetric en-/decryption of bulk data enhancing the security with the additional capability
  3. of a keyed message integrity check (keyed HMAC).

Though not necessarly depending on that, in practice TLS utilizes heavily X.509 certificates which bind

Typically, TLS support is part of the operating system based on one of the following products, which come with a BSD, GPL, or commercial license:

Programming in 'C', developers need to build there software against one of those libraries. Since they always include complex crypto-libs and compression-libs, not only the 'safety' of the depending programs, but in addition the speed (and system resources) are critically impacted.

Often (and also in case of Qmail TLS and by most other MTAs) the OpenSSL framework is used. It has a good reputation regarding speed, certainly not the best concerning system usage, but posseses a well known history of bugs. Further, the documentation is still rather weak and some functions are not documented at all (sample: SSL_CTX_set_trust).

OpenSSL is considered to be the reference implementation for TLS though it includes the older SSL mechanisms for compatibility as well. OpenSSL posses a rich set of functionalities:

This list is not exhaustive, however.

Chapter 4: TLS Protocol and Companions: Request for Comments

The OpenSSL implementation has heavily influced the outline of the TLS RFCs which I reference for completeness:

Major # Minor # Name RFCs Comments
2 0 SSLv2    
3 0 SSLv3    
3 1 TLS 1.0 2246; 3268, 3749, 3943 AES encryption added; new compression method(s)
3 2 TLS 1.1 4346; 4279, 4366, 4492, 5077 Additional handshake methods, PSK usage defined; ECC added, stateless Session Resumption
3 3 TLS 1.2 5246; 5288, 5289, 5489, 5746, 5878, 6066, 6176 IDEA + DES deprecated + PRF function; ECCDH and AES-GCM
DTLS 6375; 6083, 6520 Datagram RFCs + Heartbeat extension
3 4 TLS 1.3 8446, 8447 Ephemeral KEX based on ECCDH, encrypted auth, HDKF, 1-RTT/0-Rtt, AEAD, ChaCha, Poly1305

Personally, I find the TLS RFCs hard to understand. In particular, because they don't provide any sort of state diagram for the TLS session (I will discuss this later) but rather use programming samples, derived directly from the OpenSSL source.

Up to version 1.1 TLS was required to be backword compatible with SSLv2. From a security point of view, TLS did not provide better security than SSLv2 because it was always possible to allow a version roll-back even in the current session: session renegotiation. TLS 1.2 broke with this tradition; but typically needs to be recompiled without compatibility support.

TLS 1.3 breaks with this tradition, and only supports a few, well-known, cryptographic primitives:

Still TLS depends strongly on X.509 certificates and the PKI Public Key Infrastructure, which are layed out in others sets of RFCs:

Chapter 5: Transport Layer Security Framework

I have already mentioned some protocol elements of the TLS framework like messages and procedures. In fact, TLS is rather complex and it couples

Since computing power for en/de-cryption is not any longer a significant concern, we can assume that

Another important aspect of the TLS protocol is due to it's asymmetrical behavior between the client and the server. The server is responsible for authentication and thus to presents his X.509 certificate and actively depends on the PKI framework, while the client acts normally explicitely anonymous. The validation and verification of a server certificate is relative new in Web browsers (as TLS clients) and still lacks a common user interface (and understanding). Thus, many other TLS clients (i.e. email clients) acting in a none-interactive way have no glues how to handle TLS ALARM and authentication failure messages.

The TLS protocol is situated on top of the Transmission Control Protocol TCP or UDP and realizes additionally transport and session services, independently from TCP or UDP (see figure below).

Figure 5: Layered architecture of the TLS protocol; the ChangeCipherSpec protocol is not supported in TLS 1.3 anymore

In this sense, TLS violates the OSI seven-layer model from a structural point of view. Even more severe, the OSI concept of Service Access Points SAP is not used. It was assumed, that TLS acts 'transparently' between TCP and the application layer. Given the fact, that a potential TLS user needs to know the security context, this design decision - which has a birthmark of SSL - does not fit well into our current understanding. Severe security leakages are opened up, since the application and the user does not receive a qualified feedback about the current security context from TLS.

With RFC 6375 TLS has been enhanced to support UDP as well. In order to mitigate the none-state behavior of UDP additionally a new support protocol was supplied: The Heartbeat (RFC 6520).
Of course changing a vehicle from a four-wheel system to a five-wheel system is not a trivial task and messed up entirely in OpenSSL due to it's broken memory manager. This gave rise to the so-called 'Heartbleed-bug' which compromised a lot TLS-protected internet sites. In particular - since no counter-measure was available - the bug could actively used to copy chunks of TLS memory from the server to malicious client 'steeling' potentially even the private key of the server.

With TLS 1.3 its communication framework has been revised, because the Change CipherSpec protocol component became obsolete. This helps in particular to reduce the risk for downgrading attacks.

5.1 The 'Cipher Suite'

As we have seen, TLS provides in each aspect a set of technical solutions and propagates the chosen methods as 'Cipher Suite' coupling the following cryptographic and transmission elements (figure 6):

  1. Key exchange between partners
  2. Authentication (of the server)
  3. Symmetrical de/encryption of message
  4. Operational Mode (for block ciphers)
  5. Message Authentication and Integrity (MAC)

Figure 6: Interpretation of the 'classical' TLS 1.2 Cipher Suite

The Cipher Suite is transmitted in cleartext and given in a dash-format as: DHE-RSA-AES256-SHA or initially in an underscore format: TLS_RSA_AES256_MD5 depending on the TLS framework in use. The structure and the (valid) elements of Cipher Suite are identifed in RFCs and each combination is enumerated.

Given TLS 1.3, this list becomes very short and neither the hanshake protocol nor the server's authenticion mechansim are optionl. What is left is the symmetrical encryption scheme and the choice for the hash function. Thus, one observers typically:

The final Cipher Suite is the result of the negotiation among both communication partners and can be influenced to some extend externally as parameter prior setting up the TLS connection. Though conceptually - coupling the transport and the session layers of TLS to be considered as 'Service Access Point' - the current choice of it is available only within the closed TLS connection. However, Apache has made the information available to the outside world by means of the MOD_SSL environment parameters, which are interrogatable by the application.

It needs to be mentioned, that - within TLS 1.1 and earlier - the Change Cipher Spec protocol as part of TLS allows to change those Cipher Suites during the on-going session without explicit notification.

5.2 TLS Key Management

While the Session Management determines the dynamic behaviour of the handshake, the Key Management provides the algorithms and is responsible for it's cryptographical strength working 'under the hood' it realizes a solution for two tasks:

  1. How to generate the required keys, thus they can not easily guessed or intercepted?
  2. How to synchronize the keys between the communication partners; avoiding the insecure transmission of keys?

The strength of the TLS protocol regarding security results from the fact, that all relevant transport keys are derived uniformly and commonly for a particular session among the communicating partners from some cryptographic material. The better the KeyMaterial the better the cryptographic strength.
On the other hand, the (potential) knowledge of a (comprised) session key for one session does not necessarily impact the security of recent and/or future session. This behavior is called Perfect Forward Secrecy PFS, which is an important concept.

Here, we will discuss ephemeral key management only; though TLS allows in principal also so use of PreShared Keys.

Key Generation:

The key generation in general is given be see following steps:

  1. Handshake secret: The TLS client and TLS server are finshed with the key exchange and both have calculated the some 'point' of the curve, they have negotiated upon. Gived DJB's Edward curve Curve25519 the 'point' is simply a coordinate here < 2255-19. Thus, the 'choice' is about that large as we may observe protons in the visible universe.
  2. During the handshake, both sides have accumualted 'entropy' from the mutually received transmitted and received bytes on the network ('Hello Message').
  3. Starting with (1), (2) is used to feed a (complex) hash function HDKDF together with some additonal (3) byte strings.
  4. The resulting hash value(s) are now used to derive the final common shared secret string, aka 'traffic secret' for both sides (see fig. 6).

Figure 6: Complex but uniform scheme of TLS 1.3 generating the final keys out of the first stubs of the key material.

The mechanism for the key generation in fig. 6 includes additional steps not mentioned here.

5.3 The Record Layer

Connection states:

Chapter 6.1 in RFC 5246 introduces "Connection States" and describes those as "operating environment of the TLS Record Protocol"!

Pending states:
Initially, both client and server are in pending state exchanging Hello messages to initiate the session.

Initial Current states:
Since no security-context (this is the chosen Cipher Suite) is chosen yet, the entire communication taking place by means of the TLS Record protocol is none-encrypted, none-secured, and none-compressed. All relevant informations, including X.509 certificates and acceptable Cipher Suites are transmitted in cleartext over the network (and are interrogatable eg. by means of WireShark).

Current states:
Once the authentication of the partern (typically only the server) is verified, the ChangeCipherSpec protocol is used to setup the security context while chosing the Cipher Suite. At that point, the connection enters a 'current state'. The description of those tasks in the current RFCs (see table above) is done in programming language terms and it lacks (from my understanding) a qualified state scheme (compared to eg. the TCP protocol).

The Record Layer is actually the workhorse of TLS since does not only serves as data container but rather has to operate on the data prior of transmission; thus (fig. 7b)

  1. fragment the appliation data into chunks (segments)
  2. provide the integrity by means of calculating the keyed MAC
  3. perhaps compress the data
  4. filling up the data for block-encryption with some padding
  5. encrypt the resulting data and
  6. finally encapsulate the data into the Record Layer Frame while
  7. adding the required Record Layer Header.

It is important to mention, that the Record Layer Frame is used even at the beginning of the TLS session; but now the data are Null-encrypted (fig. 7a).

Figure 7: Tasks of the Record Layer protocol (omitting DTLS; thus TCP only)

Chapter 6: X.509 Certificates

At that point TLS could live - not considering the vulnerability of DH due to MitM attacks - without something we call Public Key Infrastructure PKI depending in practice on X.509 certificates. However, during the pioneering days of asymmetric cryptography authentication of the communication partner was a too tempting goal not be realize by the very same token.

During the last 20 years X.509 certificates were believed to be magical wand in order to secure Internet communication and is a conerstone of for your today's commercial use of the Internet. Not only 'big business' depends on cryptography (and laid down in the ANSI X9.63 standards) but it is additional attractive for crime and surveillance ....

6.1 X.509 Certificate as data container

Let's have a look into a X.509 certificate (fig. 8). Basically, a certificate (cert) carries four indispensible pieces of information:

  1. The name (= identity) if the owner, called Subject of the cert and expressed as Distinguished Name DN.
  2. The public key of the Subject.
  3. The name of the Issuer who has signed this certs; again expressed as Distinguished Name.
  4. The Signature of the Issuer for this cert providing some kind of legitimation.

In addition, there are some other technical information included:

Furthermore, a certificate does usually indicate, what is it's purported usage:

Apart from these attributes, today significant information is provided by means of so-called Extended Key Usage EKU flags. For instance, a cert may be used for code-signing. An iOS or Android developer needs to sign it's software in order be be acceptable for the Operating System prior of installation.

If you are familiar how to break down the family of Dinosaurs into their zoological names, you probably don't have difficulties following the ASN.1 naming conventions for certs ... which is a pain in the neck for most programmers and leaves unfortunately a lot of ambiguities both in creating and also in interpreting the cert's attributes.

Figure 8: Basic ingredients of a X.509v3 certificate

6.2 Presentations of X.509 certificates and Key files

The structure (and the content) of X.509 certs are well described, however the presentation depends somewhat on the purpose. Typcially, we use certs in the following forms:

OpenSSL allows to transform and to use the certs in any format. The table below shows one certificate I ship with UCSPI-SSl:

openssl x509 -in ::1.pem -text -noout

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
   d3:4a:f4:ef:87:65:d7:73
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=New York, L=Brooklyn, O=ucspi-ssl research laboratory, CN=ucspi-ssl research ca
Validity
   Not Before: Sep 27 19:03:54 2012 GMT
   Not After : Sep 25 19:03:54 2022 GMT
Subject: C=US, ST=New York, L=Brooklyn, O=ucspi-ssl research laboratory, CN=::1 Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
   RSA Public Key: (1024 bit)
    Modulus (2048 bit):
     00:cc:f7:36:a1:e8:68:d6:9a:71:df:f9:d1:40:70:
     b7:2a:7b:ee:24:ad:b2:e7:9e:83:fd:cd:7e:b0:5e:
     6d:ba:d3:11:84:9f:34:3b:44:23:c9:22:c1:ce:84:
     a6:bf:41:82:50:0d:89:78:dd:e3:c8:54:55:01:f9:
     f8:9d:87:67:36:8e:a1:07:e8:39:ec:fa:9d:46:4c:
     e7:ba:45:ef:fa:16:c9:1f:2a:4d:86:5d:ff:87:66:
     4c:1f:95:03:72:5d:3b:e8:04:46:94:70:c1:0e:72:
     2d:8b:a9:f8:fc:a0:f2:66:94:14:44:0a:a4:74:38:
     f7:dd:f6:19:ca:86:ed:3e:e3
    Exponent: 65537 (0x10001)
X509v3 extensions:
  X509v3 Basic Constraints: critical
    CA:FALSE
  X509v3 Key Usage:
    Digital Signature, Key Encipherment
  X509v3 Extended Key Usage:
   TLS Web Server Authentication
  X509v3 Subject Alternative Name:
    IP Address:0:0:0:0:0:0:0:1, DNS:localhost
  X509v3 Authority Key Identifier:
    DirName:/C=US/ST=New York/L=Brooklyn/O=ucspi-ssl research laboratory/CN=ucspi-ssl research ca
    serial:F1:8A:16:BB:FA:4F:13:E2

Signature Algorithm: sha1WithRSAEncryption
     09:dc:df:4c:d6:26:3b:0c:6a:11:89:17:1c:f4:8c:56:54:97:
     1c:a5:d9:1f:42:3a:28:9e:96:a3:d3:ab:6f:36:d0:8b:40:7d:
     f1:e3:eb:90:8c:89:ce:17:35:9e:9a:01:c8:f4:be:d5:e2:75:
     5c:04:aa:ca:5c:58:4c:c8:c6:cb:dd:55:84:78:43:2c:e3:69:
     6f:95:2c:27:fb:64:25:2b:2e:2a:6f:f1:e0:5a:b9:f3:aa:2b:
     ad:24:da:64:1f:7b:e2:19:04:ca:b2:3e:85:20:9f:e3:ad:03:
     f3:07:47:8f:a1:d1:9e:5e:55:00:b2:0b:dd:64:8c:bb:1d:f7:
     05:e7:6f:1c:a8:1a:8c:23:76:00:05:15:06:10:94:5c:90:03:
     e2:3f:b2:96:9f:91:fe:c4:8e:33:4c:a5:f5:91:43:29:07:38:
     81:94:4d:ce:e5:8a:a0:da:67:08:a3:91:25:2e:78:28:ce:71:
     52:52:98:71:4d:b8:b6:92:35:4a:e3:cd:19:22:31:86:de:d6:
     c3:e8:da:ce:ca:40:fd:07:62:ba:08:1c:a4:0d:f4:53:22:5b:
     b6:5f:8b:b7:22:17:96:6a:b7:ac:3c:f8:79:ec:e9:ea:b3:f6:
     a4:4f:36:a3:c6:36:0c:08:50:7e:53:81:a3:ca:43:5a:70:46:
     85:d9:a6:4f
 openssl x509 -in ::1.pem -text

-----BEGIN CERTIFICATE-----
MIID1jCCAr6gAwIBAgIJANNK9O+HZddzMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNV
BAYTAlVTMREwDwYDVQQIEwhOZXcgWW9yazERMA8GA1UEBxMIQnJvb2tseW4xJjAk
BgNVBAoTHXVjc3BpLXNzbCByZXNlYXJjaCBsYWJvcmF0b3J5MR4wHAYDVQQDExV1
Y3NwaS1zc2wgcmVzZWFyY2ggY2EwHhcNMTIwOTI3MTkwMzU0WhcNMjIwOTI1MTkw
MzU0WjBpMQswCQYDVQQGEwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcT
CEJyb29rbHluMSYwJAYDVQQKEx11Y3NwaS1zc2wgcmVzZWFyY2ggbGFib3JhdG9y
eTEMMAoGA1UEAxMDOjoxMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDM9zah
6GjWmnHf+dFAcLcqe+4krbLnnoP9zX6wXm260xGEnzQ7RCPJIsHOhKa/QYJQDYl4
3ePIVFUB+fidh2c2jqEH6Dns+p1GTOe6Re/6FskfKk2GXf+HZkwflQNyXTvoBEaU
cMEOci2Lqfj8oPJmlBRECqR0OPfd9hnKhu0+4wIDAQABo4HyMIHvMAkGA1UdEwQC
MAAwCwYDVR0PBAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCYGA1UdEQQfMB2H
EAAAAAAAAAAAAAAAAAAAAAGCCWxvY2FsaG9zdDCBlwYDVR0jBIGPMIGMoX+kfTB7
MQswCQYDVQQGEwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCEJyb29r
bHluMSYwJAYDVQQKEx11Y3NwaS1zc2wgcmVzZWFyY2ggbGFib3JhdG9yeTEeMBwG
A1UEAxMVdWNzcGktc3NsIHJlc2VhcmNoIGNhggkA8YoWu/pPE+IwDQYJKoZIhvcN
AQEFBQADggEBAAnc30zWJjsMahGJFxz0jFZUlxyl2R9COiielqPTq2820ItAffHj
65CMic4XNZ6aAcj0vtXidVwEqspcWEzIxsvdVYR4QyzjaW+VLCf7ZCUrLipv8eBa
ufOqK60k2mQfe+IZBMqyPoUgn+OtA/MHR4+h0Z5eVQCyC91kjLsd9wXnbxyoGowj
dgAFFQYQlFyQA+I/spafkf7EjjNMpfWRQykHOIGUTc7liqDaZwijkSUueCjOcVJS
mHFNuLaSNUrjzRkiMYbe1sPo2s7KQP0HYroIHKQN9FMiW7Zfi7ciF5Zqt6w8+Hns
6eqz9qRPNqPGNgwIUH5TgaPKQ1pwRoXZpk8=
-----END CERTIFICATE-----

cat ::1.key

-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDM9zah6GjWmnHf+dFAcLcqe+4krbLnnoP9zX6wXm260xGEnzQ7
RCPJIsHOhKa/QYJQDYl43ePIVFUB+fidh2c2jqEH6Dns+p1GTOe6Re/6FskfKk2G
Xf+HZkwflQNyXTvoBEaUcMEOci2Lqfj8oPJmlBRECqR0OPfd9hnKhu0+4wIDAQAB
AoGBAMtW4htED2X/+MMj+qU8bWq3Yi1/KULBrt6HFI1yUNgMd4+jxdSaKApt8emp
DiglnFtA4sZHE6h1iZQZYr0dTJU67NXR0iuG8/llujvP8sMyVSzEvlQ9DKNlclmO
+yKjn6t0WkTuWFijHj8a0gnZxSU1/01NAUGemaS/MG4j+NwZAkEA9Nznerg0lw7n
Xg9SJW1UEQvhiffz8kD/7J3TQCsjMktWyYCyD+zm7yo0/Az3RiMBJgzQE5TR7EsG
oZJwpk4QpwJBANZJwpqjOfgjGBiISimUdf1DsBh8D3fhQW6YE0XWMD9+7sZmOyw7
Poc19xgSE9Zc4ksG+rTr/WmJFn/C0hz6i2UCQQDyN7cvuRokt5R9ghBTf6OiPSt8
7G8/G7dOHA1Fs6ZccRRHvevmPwVuXkUNc9IDaksPlasbQ6Ko6MqFd7PBfwWPAkEA
1RM27CjN5YyP0yUCCWJUCGeb3FzPzLYxJ9UTpOebxidjKehRgmPOgwgIEOk4zHhD
k7L265uUubHUq2l/H82JeQJAQQagY+KXbztUO5k0cIltMuccSt//rxLQs4KPCsEd
TI3Xt/kcW/AZFYn5u+UO5MAihQvKBXpNm9XgxY3daHwwJg==
-----END RSA PRIVATE KEY-----

Though we used the openssl x509 routines to display the cert; since it is a .pem file we could simply use cat instead.

We notice, that the meta-information coming with the cert, like it's fingerprint, is evaluated by openssl independent of it's representation and will result always in the same values.

6.3 Authentication, Validation, Legitimation

Let's try to sort out some often used terms and explain those:

Authentication Generally spoken, a X.509 certificate binds an identity (named by it's Distinguished Name DN) with it's Public Key.
Authentication results from the possesion of the fitting private key by the identity and it's challenge by means of typically a NONCE message.
Validation I will call the checking of the syntactical correctness and (internal) consistancy of a (complex) X.509 certificate validation.
Each X.509 certificate needs to have a digital signature provided by the issuer. The issure's DN and the signature are mandatory parts of the certificate. The signature algorithm includes a hash value calculated either by means of MD5 or SHA/SHA256 and encrypted with with the issuer's private key.

A X.509 certificate includes a lot of other information to be subject of validation:
Its purported usage, the validity period and others (extended usage).
Verification The X.509 certificate provides some information regarding the identity of the sender:
  • The Subject given as Distinguished Name perhaps including the FQDN or the email address.
  • The Alternative Subject Name (occassionally abbreviated SAN) carrying the FQDN, the IPv4 and/or IPv6 address of it's owner (for networking components).
  • It's fingerprint either of the entire X.509 cert or at least of the Subjects Public Key Indicator (SPKI).
This information can be cross-checked and verified against the (external) DNS and/or IP information.
Legitimation Finally, some X.509 certificates need to be trusted. Trust is provided by means of the knowledge of superior root certificate and is to some extend a question of 'policy'. Some so-called root certificates need to be present locally a 'trust-store' belonging to the application or the OS.
External 'trust stores' may be inquired by means of the Online Certificate Status Protocol OCSP in case the respective URL is part of the X.509 certificate itself.
'Trust' is a transitive attribute spanning a series of signed certificates. By means of a Certificate chain all intermediate X.509 certificates can be provided in a series.

6.4 'root' Certificates, Signatures, and the Trust Chain

X.509 certificates which have the attribute CA:True can be used to sign subordinated certificates:

Figure 9: 'foul' trust chain

Though in general, the cert's signature includes enough (unique) crpytographic material, by means of the weak MD5 algorihm it is possible to generate rogue CA certificats with the same MD5 hash sum, but different content.

6.5 Certificate 'Usage'

Focusing the discussion on the 'usage' of the certificate, we have to consider

Since we are talking about 'asymmetrical' en/decryption, we always have to keep in mind the 'who'. In general, we have to distinguish between

  1. Standard certificates CA:False, and
  2. 'root' certificates CA:True.

The main difference is, that standard certificates require for the 'how' always a fitting private key during the transaction; while for a root certificate the private key is generally 'off line' (fig. 10).

Figure 10a: Usage of a 'root' certificate for signing
Figure 10b: Purported usage of standards certificates

The X509v3 extensions provide the framework for the proliferation of the cert's usage. Here we have:

6.6 Certificate owner's identity

Until recently, the identity or the certificate's owner was solely report by means of the Distinguished Name and here in particular (figure 11) the so-called Canonical Name CN which should equal the hostname in case of the remote computer system, or the email address in case of a personal certificate.

Given a X509v3 certificate, the Subject Alternative Name SAN may carry additional information. Here, multiple attributes are possible, e.g. commonly the IPv4 and IPv6 address alongside with the DNS FQDN. We can use the provided values to verify those against the evaluated DNS information per peer. Once the information in the certificate is correctly embedded, matching the purported values with the received one greatly reduces the risk of MitM attacks and interception.

Note: OpenSSL allows to use 'compactified' IPv6 addresses upon generation of the X509v3 certificate and expands those accordingly.

Chapter 7: TLS Applications

Once a TLS connection is established, there could be up to 255 applications to use this 'session'. In practice, however, it is only one. The reason is, that an application either requests a TLS connection as client or is in listening mode.

The listening mode (server mode) can be established in three ways:

  1. The application is linked with the OpenSSL (or other implementation) library, thus 'speaks' the TLS protocol. In order to interprete the TLS messages correctly, a separate port has to used and commonly deployed (eg. HTTPS: port='443' instead '80').
  2. The application facilitates an underlying transport service which does in turn provides the TLS service transparently to the application:
  3. We use a 'trick' to switch to the TLS service while the application has already been started in native (unencrypted) mode: STARTTLS or STLS:
    • SMTP: RFC 3207 'SMTP Service Extension for Secure SMTP over Transport Layer Security'
    • POP3: RFC 5034 'The Post Office Protocol (POP3)'
    • IMAP4: RFC 2595 'Using TLS with IMAP, POP3 and ACAP'
    • LDAP: RFC 2830 'Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security'
    The application needs to be explicitly enhanced to support STARTTLS/STLS which only has been defined for the very few protocols mentioned above. We discuss STARTTLS in case of SMTP in more detail below.

Most of the TLS-aware appplications follow the first approach, thus use directly e.g. the OpenSSL programming interface (API). For this purpose, OpenSSL provides special network functions (named BIO* routines) which can be called from the application directly, instead of the standard socket routines.

With respect to security, a few important aspects are touched:

  1. The whole TLS mechanism, including X.509 certificate treatment, takes place in the (user) context of the application. While this is fair for a TLS client application, this might be unacceptable for a TLS server. Thus, there is no isolation between the TLS context and the application itself. Given the fact that a TLS server application might posses (we see that later) several identities, it is is not easy to realize the required privacy with this approach.
  2. Since the implementation of in particular the OpenSSL libraries are changing in time, we need to recompile and relink our application to cope with those changes. This is in particular required in case a security issue is identified in a certain version, which unfortunately happens.

7.1 UCSPI-SSL

The concept of D.J. Bernsteins's UCSPI-TCP has been picked by Superscript's William Baxter to provide the same type of client/server communication but now based on OpenSSL's TLS services instead the standard TCP sockets called UCSPI-SSL.

While OpenSSL also include sets of network I/O calls named *BIO routines UCSPI-SSL still uses the low-level routines for communication. UCSPI-SSL comes with two main programs:

In fact, sslserver and sslclient provide the same UI (options and flags) as their brothers and in particular sslserver reads the same cdb for a controlled access of remote clients. Thus, UCSPI-TCP and UCSP-SSL are installed side-2-side on most systems because UCSPI-SSL does not provide capabilites to generate the cdb and does not come with extra services like for instance rblsmtpd.

7.2 Recent Developments of UCSPI-SSL

The original UCPSI-SSL software was written and released in D.J. Bernstein's slashpacket format back in 2001 by William Baxter at Superscript.

Scott Gifford subsequently enhanced the original implementation to allow a 'delayed' negotation of the TLS session, which is required by STARTTLS and STLS.

Since the development of UCSPI-SSL was stalled in 2008, and I was on the way to include TLS support into qmail-remote, while SPAMCONTROL's qmail-smtpd was already successfully STARTTLS-enabled in 2006 (version 2.4), I took the chance to integrate all the required patches to UCSPI-SSL und create the follow-up version 0.8. Currently, UCSPI-SSL 0.12 is mature, including full support for IPv6 and TLS 1.3.

7.3 UCSPI-SSL working model

The original implementation of UCSPI-SSL behaved 100% comparable to UCSPI-TCP except for it's cryptographic operations using the OpenSSL framework. Mainly two programs are in use:

  1. sslserver providing a 1:1 implementation of tcpserver capabilities.
  2. sslclient again, beeing the cryptographic twin of tcpclient.

In addition, some 'helper' programs exist, like sslhandle and https@. Further, William Baxter included sslperl into UCSPI-SSL.

7.4 The sslserver

Access to the Key Store and Trust Store, where the certs and the key-files live is realized in a 'sandbox' by means of a suid to a low-privileged system user having access to the sensitive information. UCSPI-SSL does not provide a store for the Certificate Revocation List CRL and does not come with a OCSP client to lookup the cert online according to the information provided in the cert.

Figure 11a: Standard use of sslserver for TLS encryption on port 465
Figure 11b: 'Delayed' TLS negotiation by means of Scott Gifford's StartTLS option

From a functional point of view, these two deficiencies are not relevant for in particular the typical use case of sslserver. However - more relevant - in my implementation of UCSPI-SSL I added Certificate Chain Support.

Currently, there are two other implementation features missing:

Both missing features concern the performance and perhaps scalability of UCSPI-SSL, which however was developed with a small memory footprint in mind.

Standard sslserver use:

Figure 11a shows the 'old' behavior of sslserver acting as complement for tcpserver while reading from and writing to the network the SSL sockets and feeding the (unencrypted) values to the application by means of the file descriptors FD 0 and FD 1.
From the user's persepective, the only change is the additional Key Store and Trust Store to be included using the environment variables CADIR, CAFILE, CERTCHAINFILE, KEYFILE and additionally the Diffie-Hellman domain parameters DHPARAM. Unlike other implementions, there is no explicit central store to be read. Access to those files is granted setting up Unix read permissions for a particular user SSL_USER beeing part of SSL_GROUP. While reading the stores, the effictive user-id is switched to the provided values and never exposed to the user of the current sslserver session.

We also realize the casual tcpserver capabilities, reading the cdb and exporting the read environment variables to the target application. Additionally, an IDENT lookup is performed (uncommon now) and not only the IP address of the client is provided to the application, but by means of Dan Bernstein's DNS libs, the FQDN is evaluated and serves as useful information too.

Note: In the current UCSPI-SSL implementation, I included CIDR support for both IPv4 and IPv6 connections.

Let's have a look at the four relevant moments in time as shown in figure 11a:

  1. T=a: sslserver is listing to a specifc port an a specific IP address of the server (or all). It receives a TCP SYN from the client and starts to work. Upon start it has read the Key Store and the Trust Store while loading the certificates and keys into it's memory.
  2. T=b: Depending on the provided options for IDENT and DNS lookup, sslserver tries to gather the information from the remote site; the DNS respectiveley. This information (together with the IP address of the connection) is used to lookup the cdb. In general, accept or deny rules are given.
  3. T=c: in case of an accept the next program is spawned, according to the call of sslserver. In the sample qmail-smtpd is called next, but in reality it might be rblsmtpd or perhaps greylistd in the first place while feeding the decrypted information read from the network on FD 0 to the called routine.
    Invoking sslserver with the option -e, the TCP environment variables are stored in the environment; with additionally the TLS informations are expressed as mod_ssl.
  4. T=d: The child program now can send it's response via FD 1 to sslserver, which will encrypt the information and send it to the remote client.

It is important to understand that the entire procedure realized by sslserver is completely opaque, that means invisible for the called program, unless it has a particular built-in knowledge.

sslserver using the StartTLS option:

Employing STARTTLS however, the different behaviour of sslserver is shown figure 11b:

  1. sslserver is instructed by means of the '-n' (not yet) option to accept unencrypted connections in the first place; typically listing for SMTP traffic on port 25.
  2. Both sslserver and the called client program - in our case qmail-smtpd - communicate by means of the file descriptors FD 0 and FD 1 in the usual way, though these file descriptors or soleley reserverd for un-encrypted commuication.
  3. The STARTTLS behavior needs to be triggered for the client application qmail-smtpd (or qmail-pop3d providing the STLS command) by means of the environment variable UCSPITLS="". Subsequently, qmail-smtpd offers the STARTTLS ESMTP verb to the client.
  4. Once the SMTP client honors STARTTLS, which is recognized by qmail-smtpd, now three additional file descriptors are chosen by sslserver and used by qmail-smtpd:
    • SSLCTLD a control socket used to trigger the STARTTLS operation.
    • SSLREAD the socket to read the encrypted information.
    • SSLWRITE the socket to write the encrypted information.
  5. While sslserver is responsible to care about the SSL context and setting up the connection while reading from the Key Store and Trust Store in a setuid environment, and - upon connection - promotes the mod_ssl TLS environment variables to the called program. Thus, qmail-smtpd is not directly involved in any cryptographic operation and 'knows' about the TLS environment only by means of the received environment variables.
Setting up sslserver

In order to call sslserver and it's client program, we need to become familiar with sslserver's

sslserver command line syntax:

sslserver requires upon start at least the local IP(v4/v6) address and target port to bind with, and the (child) application to run. In case '0' is provided for the local IP address, sslserver binds to all available local (unicast) addresses of the machine. Usually, the port is given explicitely, though you can chose a port for /etc/services like SMTPS.

Figure 12 shows the rich variety of options permitted by sslserver. Typically used are the following:

Logging of sslserver's actions (not very prosaic) is done by means of the option -v.

Figure 12: sslserver command line options and arguments

sslserver's environment variables:

Until now, sslserver seems to have no ideas about the required Key Store and Trust Store and how to read it's own certificate .... However, if we look at the required environment variables, we find the following sets:

The reading and processing of those files can be modified by means of some additional environment variables:

Aport from those file locations, the behavior of sslserver can be influenced by the following environment variables:

Since these parameters are given per environment variable, their setting might not to only to be 'global' for the entire sslserver process but rather may depend on the connecting client using the cdb mechanism. For instance, we may issue different server certificates based on the incoming IP address.

Requesting client certificates:

The TLS protocol is asymmetrical: Only the server needs to authenticate while the client stays anonymous. This is the reason, while typically upon - lets say a HTTP connection - you have to authenticate additonally by means of userid and password.

However, TLS allows mutual authentication of both parties. But there is a price to pay:

In practice, the server's administrator has setup an own Certificate Authority which is used to provide the personalized client certs which are roled-out together with the matching Keyfile to the clients. The server now uses the CA cert (often a self-signed root certificate) to tell the clients: 

      "If you like to authenticate with your certificate, it has to match the CA cert which
      I provide to you in the first place!"

Thus, there are these steps to consider for client certificate verification:

  1. A CA cert needs to be created to sign the client's certs and it has to be deployed to the server as 'client CA cert' CCAFILE in our case.
  2. The client cert alongside with the matching private Keyfile (and perhaps in addition the CA cert for the server has to be deployed to the clients and registered into their Key Store and Trust Store respectively.
  3. The server has to be instructed to request a valid cert from the client and by the same token to promote all it's know CCACERTs which is triggered in case of sslserver by means of the global option -z - or much more useful - setting the environment variable CCAVERIFY perhaps for specific IP addresses.

7.5 The sslclient

UCSPI-SSL's sslclient ist used as base for the auxiliar programs sslcat and https@. Unlike sslserver it uses file descriptor 6 ('&6') for reading and file descriptor 7 ('&7') for writing to the child. Further, it reads the certs and it's keyfile (which my be password protected protected) by means of arguments:

Figure 13: sslclient command line options and arguments

The best way to illustrate how sslclient can be used connecting to public servers can be picked up from the https@ script:

#!/bin/sh # WARNING: This file was auto-generated. Do not edit! if [ "${1}" = "-4" -o "${1}" = "-6" ] then vers=${1} shift else vers="-6" fi host=${1-0} path=${2-} port=${3-443} args="" if [ $# -gt 3 ] then shift; shift; shift args="$@" fi echo "GET /$path HTTP/1.0 Host: $host:$port " | /usr/local/bin/sslclient -XRHl0 "$vers" $args -- "$host" "$port" sh -c ' /usr/local/bin/addcr >&7 exec /usr/local/bin/delcr <&6 ' | awk '/^$/ { body=1; next } { if (body) print }'
Listing 1: The https@ script

Apart from setting some arguments to be transfered to sslclient in the first piece of the script, we recognize, that - following the 'echo' - the input to the 'echo' is redirected to file descriptor '&7' and the result is taken from '&6' to be subject of the programs delcr and awk. It is important to realize, that the both programs addcr and delcr are supplied by UCSPI-TCP(6); thus the script won't run without their help. In the current version of the script, I added -X as an argument for sslclient. Otherwise, the sslclient would ask for the (Web) server's certificate and fail, since no CA cert is provided or perhaps available via the Trust Store.

7.6 The Key Store and Trust Store

Within UCSPI-SSL there are some standard locations fo certs: /usr/local/ssl/certs which is defined in conf-cadir. For the Diffie-Hellman parameter file, the default location /usr/local/ssl/pem/dh1024.pem is used.

In general, we need to take care about:

In general, all these files shall be put in the same directory with as little as possible permissions while readable by SSL_USER and evaluated in the chroot environment as defined by SSL_CHROOT. This of course holds for the Key Store while the certs and the DH parameter file are by definition public.

For standard sslserver operations, we don't need a particular Trust Store. However in case we are using sslclient, the situation is different. Comparable with Web browsers, a Trust Store has to be provided. For this purpose, we use the CADIR capabilities:

Let's give it a try with the certs provided in UCSPI-SSL:

openssl x509 -subject_hash -in rootCA.pem -noout
  1346b848
openssl x509 -issuer_hash -in ::1.pem -noout
  1346b848

Thus, the generic file name of my rootCA.pem in the CADIR would be 1346b848.0, where the '0' indicates that this is the first cert with this hash (others may flollow, if newly generated). The very advantage of this method is, that the name of the CA cert stays independent from it's i.e. Serial Number.

Unlike traditional (DL) Diffie-Hellman, for DHEC (applying any curve) no particular DH params are required:

Chapter 8: Lose ends upon TLS cryptography

NSA interception

In spite of the current NSA surveillance affair, the believe in public key cryptography is somewhat undermined. Some cryptographic functions TLS offers are directly influenced by the NSA.

Quoting Eric Rescorla from his book SSL and TLS (page 105): 

      "FORTEZZA was originally designed by the NSA to provide strong cryptography while allowing
      the NSA to intercept communications. The conflict between these goals was resolved by incorporating a
      key escrow feature into the device. Each card had its own key, which was escrowed with the NSA.
      Thus, when the NSA wished to decrypt a communication, it could recover the key for the card used to
      encrypt it, but the encryption would be secure against all other attacks."

FROTEZZA was specified in SSLv3 but removed in TLS.

Cipher Strength

With UCSP-SSL and my implementation into s/qmail you can control the level of security by means of the Cipher Suite as shown in the samples. To some extend, you can also be protected against roll-back attacks. However, in case the OpenSSL library has some specific bugs or perhaps 'forged' cryptographical routines, there is little I can do about that. Please watch the isssued CVEs perhaps reinstall OpenSSL, bind UCSPI-SSL with the new libs and reinstall.
From my point of view, the RSA key exchange is too weak these days, Diffie-Hellman is by far better. Using ECC, the standard Elliptical Curves and there parametrization with TLS are at least guided by the NSA while beeing standardised by NIST.

Broken CA trust system

On the other hand - again in my oppinion - the entire trust system, PKI is depending upon, is broken. It irrelevant, if the certificate is signed by RSA, DSA or ECDSA; once you control the Trust Center, you rule the game. The Dutch CA DigiNotar (among others as well) was comprised to do so.

Peer X.509 certificates still do work, though.

State of a TSL connection

Not providing the security state to the upper layer is a considerable design flaw. The problem is double-present in case a TLS ALRM message needs to get issued. In case this happens, (hopefully) the application is getting terminated but without any reason, the user is informed for. This is bad by design.

IDNs, the hostname, and the SAN

Unlike the old days; domain names in the DNS may carry 'umlauts', hebrew, arabic and other characters: International Domain Names IDN. To code those characters PunyCode has been developed.
I'm not sure how to support this in X509 certificates and in particular how to match those.
Parsing and comparing is a poisoned operation.

Authentication and Authorization by means of DANE

The DNS-Based Authentication of Named Entries (DANE) (RFC 6698) is a hot topic as candidate to replace the Public Key Infrastructure (PKI). With DANE, the server's public key is stored in the DNS Zone file of the provider of the server itself. This ensures a-priori authorization of the public key and authentication can be guaranteed if the transmission of the public key by means of DNS is uncompromised. This may be subject of DNSSEC or CurveDNS.

Post-Quantum Cryptography

The key exchange as all as any signature algorithms based upon mathematical trap-door function (what we call asymmetrical cryptography) are broken by Quantum Computers. Methods, which are believed to be PQC are under development for both cases. CRYSTAL an NTRU are in particular two schemes for the key exchange based on finite fields on a lattice. Goolge's New Hope did follow the same scheme.

I will continue to work on UCSPI-SSL to include those mechanisms, however until there is no standardization, it is purely academic.

Further information about TLS can be found here: RFC Sourcebook.

Disclaimer: This page may contain outdated, or even misleading statements. Help me to improve it! This is work in progress.