ALPACA Updates

Here we give updates on the ALPACA attack.

Reevaluation 2021 by Jannik Hölling

In 2021, Jannik Hölling revisited the ALPACA attack in his bachelor thesis under supervision by Juraj Somorovsky at the Paderborn University. In his thesis, Jannik examined the feasibility of the recommended countermeasures (ALPN, SNI) in TLS libraries, the state of countermeasures in TLS applications, and the deployment level of these countermeasures on the Internet. A big thanks to Jannik for these results! If you have any questions for him, you can contact him at jannik.hoelling(at)uni-paderborn(dot)de.

TLS Libraries

With respect to TLS libraries, Jannik found that all ten examined TLS libraries allowed the strict validation of the ALPN extension. Three libraries required a manual validation after the handshake in the client, and a callback function that is used during the handshake in the server. Three other libraries supported strict ALPN validation as an optional feature, and for the remaining four this was the standard behavior.

Library Strict ALPN Client Strict ALPN Server TLS Alert 120
OpenSSL 1.1.1 Manual (Post-Handshake) Callback Standard
BoringSSL Manual (Post-Handshake) Callback Standard
Botan 2.18.1 Manual (Post-Handshake) Callback Standard
GnuTLS 3.7.1 Option Option Manual (Post-Handshake)
BearSSL 0.6 Option Option Standard
wolfSSL 4.8.1 Option Option Standard
mbedTLS 2.18 Standard Standard Standard
Java 11 Standard Standard Standard
Go 1.17 Standard Standard Standard
Rustls 0.20 Standard Standard Standard

For SNI support, Jannik found that the situation is more diverse and complicated. Although all libraries allowed strict SNI validation, many required a callback function in the server. For Java 11, strict SNI validation in the client was only an option for HTTPS, while other application level protocols require manual validation after the handshake. Three libraries (BearSSL, Go, Rustls) do not allow to send the proper TLS alert 112 in case of validation failure in the server.

Library Strict ALPN Client Strict ALPN Server TLS Alert 112
OpenSSL 1.1.1 Option Callback Standard
BoringSSL Option Callback Standard
Botan 2.18.1 Standard Callback Standard
GnuTLS 3.7.1 Standard Callback Manual (Post-Handshake)
BearSSL 0.6 Standard Callback Not Possible
wolfSSL 4.8.1 Option Standard Standard
mbedTLS 2.18 Option Callback Standard
Java 11 Manual (Post-Handshake) Option Standard
Go 1.17 Standard Manual (Post-Handshake) Not Possible
Rustls 0.20 Standard Manual (Post-Handshake) Not Possible

Jannik recommends that TLS libraries implement optional or standard support for ALPN and SNI strict validation, so that callback functions and manual post-handshake validation are not necessary. Libraries that do not support sending the alert should provide a possibility to do so.

TLS Application Servers

For application servers using TLS, Jannik found that of 14 servers, five (nginx, exim, Filezilla, vsftp and Courier) now implemented strict ALPN validation as a countermeasure to the ALPACA attack. In addition, LightHTTPD already supported strict ALPN validation before the ALPACA publication.

Sendmail only implemented countermeasures at the application protocol level, and did not yet implement ALPN or SNI strict validation.

ProFTP and vsftpd were the only servers that implement strict SNI validation.

All servers with strict validation send the correct alert, except for FileZilla (which is using GnuTLS).

Jannik also found a bug in Exim's ALPN serialization that was the result of a misunderstanding of the TLS library documentation.

In summary, only vsftp implemented strict ALPN and SNI validation fully, while the other application servers have room for improvements.

Server ALPN SNI Comment
nginx 1.21.4 Strict Permissive
Apache 2.4.51 Permissive Permissive
Lighthttpd 1.4.59 Strict Permissive
Sendmail 8.17.1 No Support No Support
Postfix 3.6.3 No Support Permissive
Exim 4.95 Strict Permissive Bug in Serialization
OpenSMTP 6.8.0 Permissive Permissive
Dovecot 2.3.13 No Support Permissive
Courier 1.1.5 Strict Permissive
Cyrus 3.4.2 Permissive SNI ALPN Strict for HTTPS
Pure-FTPd 1.0.49 No Support Permissive
ProFTPD v1.3.8rc2 Permissive Strict
FileZilla Server 1.1.0 Strict Permissive
vsftpd 3.0.5 Strict Strict

Internet Scan

Finally, Jannik also scanned the IPv4 address space for application servers with ALPN and SNI support. His scan demonstrates that by the end of 2021, almost no application servers have been updated with strict ALPN or SNI validation. The one exception is the update of Exim 4.95, which caused 0.39% of all STMPS servers on port 465 to implement strict ALPN validation.