Here we give updates on the ALPACA attack.
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.
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.
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 |
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.