SMTP and Transport Layer Security (TLS) [Tutorial]
2022-01-09 - 4th revision
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.
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:
- [TLS] Including Transport Layer Security while transmitting the message from Host-to-Host (between MTAs), thus altering the SMTP transport protocol.
- [S/MIME, PGP] Encrypting/Signing the message as part of the transmitted Data body. This incorporates end-to-end (Person2Person) confidentially and requires a recognizable, particular labeled MIME part of the message. Thus, a particular suited Email client MUA is to be used; probably employing some kind of plug-in.
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:
- Protection of the Username and Passphrase during SMTP authentication.
- Legitimation and authentication of the SMTP server by means of a valid X.509 public certificate and the corresponding private key.
- Authentication of the email sender (the user) in case a particular X.509 peer certificate is presented as requested by the SMTP server. In this case, an authenticated user may be allowed for relaying.
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
- Confidentiality - against espionage: Using encryption
- Integrity - against manipulation: Using hashsums and checksums
- Availability - against sabotage: Applying redundancy
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):
- Confidentitiality and Correctness
- Authentication and Authorization
- Reliability and Robustness
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.
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 gives an overview what happend in the field of cryptography since 1970:
- Yellow boxed denote asymmetrical cryptography.
- Magenta boxes show the development of hash functions.
- Orange boxes are forseen for achievements in symmetrical encryption.
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:
- Symmetrical encryption empying the same key and the same functions for en- and decryption.
- Hash functions using roughly the same math as symmetrical block encryption, but how serve as none-injective functions.
- Key Exchange functions employing trapdor math implementations, allowing either a key encryption method KEM or a key exchange method KXM.
- Signature functions allowing to sign data, thus the origin and authencity can be guaranteeed (signing and verification).
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
At that time, cryptographers developed hybride encryption techniques based on
- Asymmetric Public Key/Private Key encryption like Diffie-Hellman and RSA to allow the exchange/secret agreement on a
- shared secret key for fast symmetric en-/decryption of bulk data enhancing the security with the additional capability
- of a keyed message integrity check (keyed HMAC).
Though not necessarly depending on that, in practice TLS utilizes heavily X.509 certificates which bind
- an identity referenced by it's Distinguished Name DN with
- it's public key
(including the method how it is derived)
as available/deployed within the
- Public Key Infrastructure PKI.
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:
- The basic SSL and TLS routines to support the protocol in a client/server fashion.
- The crypto libraries supporting the (ever changing) cryptographic functions of the protocol accessible by a common API named EVP.
- Message digest routines calculating hashes for arbitrary data.
- The routines dealing the X.509 generation, validation, verification, and manipulation.
- A parser for the ASN.1 protocol, the description language of the X.509 certificates.
- A higher-level network programming stack named BIO* routines.
- Sample client/server programs for test purposes.
- A sample Mini-CA (Certificate Authority) application.
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|
|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:
- The TLS handshake uses solely ECC Diffie-Hellman (with a set of 'good' curves.
- TLS 1.3 tries to move as early as possible into an encrypted state followed by the authentication (basd on X.509 certs).
- Symmetrical encryption is either AES-GCM (preferred) or ChaCha20+Poly1305 (from Dan Bernstein).
- Given these methods, an additional hashsum is not required anymore but left there for backward compatibility.
Still TLS depends strongly on X.509 certificates and the PKI Public Key Infrastructure, which are layed out in others sets of RFCs:
- RFC 2459: 'Internet X.509 Public Key Infrastructure - Certificate and CRL Profile'
- RFC 2560: 'Online Certificate Status Protocol - OCSP'
- RFC 3029: 'Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols'
- RFC 3279: 'Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile'
- RFC 3183: 'Domain Security Services using S/MIME'
- RFC 3779: 'X.509 Extensions for IP Addr and AS ID'
- RFC 4945: 'The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX'
- RFC 5280: 'Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile'
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
- Transport and session layer functions
- with the cryptographic approaches based on the
- X.509 certificate PKI framework to allow
- partner authentication, legitimation, and revocation.
Since computing power for en/de-cryption is not any longer a significant concern, we can assume that
- the none-cryptographic, i.e. state (and thus dynamic) behavior of TLS is a major performance concern, while
- the cryptographic algorithms available (and chosen among the communication partners) along with the size of the keys, determine the strength of the confidentially and
- the PKI framework accounts for the authentication and (potential) legitimation of the communication partner.
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.
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
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):
- Key exchange between partners
- Authentication (of the server)
- Symmetrical de/encryption of message
- Operational Mode (for block ciphers)
- Message Authentication and Integrity (MAC)
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:
- How to generate the required keys, thus they can not easily guessed or intercepted?
- 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.
The key generation in general is given be see following steps:
- 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.
- During the handshake, both sides have accumualted 'entropy' from the mutually received transmitted and received bytes on the network ('Hello Message').
- Starting with (1), (2) is used to feed a (complex) hash function HDKDF together with some additonal (3) byte strings.
- 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).
The mechanism for the key generation in fig. 6 includes additional steps not mentioned here.
5.3 The Record Layer
Chapter 6.1 in RFC 5246 introduces "Connection States" and describes those as "operating environment of the TLS Record Protocol"!
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).
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)
- fragment the appliation data into chunks (segments)
- provide the integrity by means of calculating the keyed MAC
- perhaps compress the data
- filling up the data for block-encryption with some padding
- encrypt the resulting data and
- finally encapsulate the data into the Record Layer Frame while
- 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).
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:
- The name (= identity) if the owner, called Subject of the cert and expressed as Distinguished Name DN.
- The public key of the Subject.
- The name of the Issuer who has signed this certs; again expressed as Distinguished Name.
- The Signature of the Issuer for this cert providing some kind of legitimation.
In addition, there are some other technical information included:
- The cert's serial number for identification purpose.
- The cert's life time as expiring date.
- The algorithm, how the public key was generated.
- The hash algorithm of the Signature.
Furthermore, a certificate does usually indicate, what is it's purported usage:
- For Signing other certificates. In this case, wie call it (not precisely) a root certificate and it carries the critical flag CA=true, where 'CA' means Certificate Authority.
- For Authentication of a server, a client, a domain, or perhaps a person.
- For Key Exchange.
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.
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:
- The .pem (Privacy-enhanced Mail) format using the ASN.1 Distinguished Encoding Rules while the 'file' is human-readable including the information in a BASE64 description as well.
- The .crt (abbriviation for 'certificate') format suited to store the cert in binary form in a Key Store.
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
Version: 3 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=New York, L=Brooklyn, O=ucspi-ssl research laboratory, CN=ucspi-ssl research ca
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):
Exponent: 65537 (0x10001)
X509v3 Basic Constraints: critical
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
Signature Algorithm: sha1WithRSAEncryption
|openssl x509 -in ::1.pem -text
-----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:
|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:
- At the top of the hierarchy chain we have so-called root certificates which are distinguished from all others since we they are characterized by Subject-DN = Issuer DN.
- The signature of a cert includes a hash of the subject's DN, the provided public key and the given certificate extensions, the cert's serial number and validity period finally encrypted with the Issuer's private key.
- Intermediate certificates carrying the flag CA:True play an important role in the PKI. However, if we succeed to infiltrate one CA, the depending certs are perfectly legitimate; thus we can not distinguish 'true' from 'fake' certs (fig. 9).
- Typically, only some root certificates are present in your so-called Trust Store. In order to verify the legitimation in the trust chain every intermediate certificate needs to be known: the Trust Chain. It is common, that the node possessing the cert to validate provides upon connection in addition the missing intermediate certificates: Certificate 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
- 'Who' is using the certificate?
- 'How' is the certificated used?
- The service for 'which' purpose the certificate shall be used?
Since we are talking about 'asymmetrical' en/decryption, we always have to keep in mind the 'who'. In general, we have to distinguish between
- Standard certificates CA:False, and
- '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:
- Key Usage KU:
Typically Key and/or Data encipherment.
- Extended Key Usage EKU:
Client and/or server authentication (some older Netscape attributes are no longer in use).
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:
- 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').
- The application facilitates an underlying transport service which does in
turn provides the TLS service transparently to the application:
- We use a 'trick' to switch to the TLS service while the application has already been started
in native (unencrypted) mode: STARTTLS or STLS:
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:
- 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.
- 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.
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:
- sslserver the TLS enhancement of tcpserver and
- sslclient the pendant of tcpclient.
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
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:
- sslserver providing a 1:1 implementation of tcpserver capabilities.
- 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:
- Session Renogitiation which is cryptographically doubtful to some extend, since it undermines PFS.
- Session Caching which could be used to save resources as well.
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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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
- call options and parameter, thus its syntax in gerneral and
- environment variables; in particular to point those to the Key Store and Trust Store.
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:
- sslserver doesn't run as root but rather is instructed to drop privileges and run as -u qmaild for instance. (and a specific group as well).
- The number of concurrently running sslserver instances is provided by -c; the default is 40.
You control acceptance of incoming TCP connections by means of a -x cdb. If you don't use -X sslserver refuses to run, if no cdb is found.
In my implementations, the cdb.txt allows IPv4 and IPv6 addresses to be included in a CIDR format, for instance 2001:/8:accept. Compactified IPv6 adresses are expanded.
In any case, you need to install UCSPI-TCP6 to generate the rule-base.
- In case you run sslserver to service connections from the Internet, you will additionally
check - based on the received IP address - the FQDN of the client -h and match
this information back being 'paranoid' -p. This allows you - together with the a cdb rule
to reject DNS unqualified clients (mostly spammers in case of the SMTP protocol).
Probably, the IDENT lookup is removed -r; otherwise your connections typcially seems to 'hang' (until it times out).
- sslserver is dual-stacked accepting IPv4 and IPv6 connections in case '0' is provided
as local IP address. However you can force sslserver to bind exclusively to either an IPv4 or
IPv6 address (which is the preferred setting).
In case your IPv6 address is link-local you need to tell sslserver the -i ifname interface name; typically for Linux eth0; for most BSD systems you figure out the driver name via ifconfig and place it here: -i bge0.
- Coming to the TLS options, now you have to specify -n once you bind to an 'unsecure' port
and allow StartTLS/STLS. Probably, you have to tell the server application to issue the 'STARTTLS'
command, which is facilitated for my qmail-smtpd by means of the environment variable
Once your KeyFile is protected by a passphrase, you can provide it reading from the file descriptor 3. However, for an un-attended server, usually the KeyFile is unprotected.
In order to evaluate the current SSL state for our application, you put those into the environment,
via -s alongside with the TCP environment -e.
- In the special case, you are requiring a X.509 certificate from the connecting client, you aditionally specify -z. But this requires additional care, as discussed below.
Logging of sslserver's actions (not very prosaic) is done by means of the option -v.
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:
- DHFILE: Qualified name of the Diffie-Hellman parameter file in PEM format (default).
- CERTFILE: Path to the X.509 certificate file in PEM format.
- KEYFILE: The file, containing the private key for CERTFILE.
- CERTCHAINFILE: Concatinated CA certificates; the last one is the server's own cert and completed by the KEYFILE.
- CADIR: Directory (Trust Store) holding the CA certs with file name corresponding to their Subject's fingerprint in PEM format.
- CCAFILE: File containing CA certs for the connecting clients in case it is required to present it's cert.
The reading and processing of those files can be modified by means of some additional environment variables:
- SSL_USER: The user reading the cert and key files.
- SSL_GROUP: The group for reading the cert and key files.
- SSL_UID: The UID associated with the SSL_USER.
- SSL_CHROOT: Reading of the cert and the keyfiles is performed in this chroot directory.
Aport from those file locations, the behavior of sslserver can be influenced by the following environment variables:
- CIPHERS: List of valid TLS Ciphers for the connection.
- VERIFYDEPTH: Number of accepted certs in the chain; default = 1.
- CCAVERIFY: Triggers client certificate request and verification.
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:
- The server's certificate is usually public available. In case of SMTP email over TLS, it may be als well self-signed or even completely omitted if Anonymous Diffie-Hellman is used (the preferred method for instance for Postfix).
- In case client authentication is required by means of a X.509 cert, the server has the obligation to provide the required matching credentials (CA certs).
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:
- 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.
- 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.
- 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:
The best way to illustrate how sslclient can be used connecting to public servers can be picked up from 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:
- Our own certificates to present to the client, provided by CERTCHAINFILE or simply CERTFILE.
- The correspondig keyfile for our own cert, identified to sslserver as KEYFILE.
- The Diffie-Hellman parameter file given as DHFILE - used for discrete log (DL) DH only.
- The CADIR consisting of individual CA cert files.
- The CCAFILE including a concatinated set of potential client CA's. Using client verification, the client needs to present it's own cert matching one of those CAs.
Now, the Trust Store consists of:
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:
- Upon reading the server's certificate, the client recognizes the Issure's Distinguished Name DN and computes the hash value for this entity.
- Since the Issuer's DN of the cert to verify is identical with the Subject's DN of the Issure we can use this hash value as unique filename for CA certs in the Trust Store.
- The client now simply needs to look up this specific file and and can disregard all others.
Let's give it a try with the certs provided in UCSPI-SSL:
openssl x509 -subject_hash -in rootCA.pem -noout
openssl x509 -issuer_hash -in ::1.pem -noout
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:
- Given the curve, the modulus (as prime number) is part of it; eg. for curve25519 it is p = 2255-19.
- The generator can be considered the start point on the curve. This is provided as fixed parameter in for the curve as well. Again, re-calling curve25519 the x-coordinate x = 9 is chosen as basepoint; why the y-coordinate follows directly for the curve's equation.
Chapter 8: Lose ends upon TLS cryptography
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.
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.
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.