You are here

Alpaca Attacke

Keywords: 
alpaca, tls
Description: 

Alpaca (application layer protocols allowing cross-protocol attacks) [1] is a TLS protocol confusion attack. Under certain conditions, a man-in-the-middle attacker can successfully mix up HTTPS with other protocols such as FTPS, IMAPS, POP3S and extract sensitive information like cookies. All network services using TLS should strictly validate SNI and ALPN fields in a TLS handshake to prevent Alpaca.

Airlock Gateway validates the SNI field by default (checkbox "Strictly match FQDN and aliases" on virtual hosts) during a TLS handshake and can therefore not be tricked to accept TLS connections intended to a different TLS service on a different domain.

Note that any vulnerable TLS service (other than HTTPS on Airlock) can negatively affect the security of Airlock clients because a man-in-the-middle attacker could potentially execute JavaScript code in the victims browser by redirecting the HTTPS connection to a vulnerable TLS service (see resolution).

Resolution: 

We recommend to activate the Option "Strictly match FQDN and aliases" on all virtual hosts if possible. Clients that do not support Server Name Indication (SNI) cannot access virtual hosts that have this setting enabled. However, SNI has been supported by all major browsers for years (https://caniuse.com/?search=server%20name%20indication).

Further, if all of the following conditions are met, your setup may still be vulnerable to an Alpaca attack and actions may be required. If you think your setup is vulnerable, you can contact Airlock support for further advise.

  • Besides HTTPS (Airlock Gateway) there are other protocols such as FTPS, SMTPS, POP3S, IMAPS (TLS based) running under the same domain (e.g. ftp.example.com and www.example.com).
  • The two TLS services sharing the same domain use a certificate that is valid for both subdomains (e.g. wildcard certificate like *.example.com).
  • The non-HTTP service (not Airlock) does not implement a strict SNI header check. This can be tested with the "-servername" argument of the openssl s_client command. Example:

A wrong SNI name results in a connection error (we have activated "Strictly match FQDN and aliases" on www.ergon.ch):

openssl s_client -connect www.ergon.ch:443 -servername badSNIname.com​​​​

Correct SNI name results in a successfull connection:

openssl s_client -connect www.ergon.ch:443 -servername www.ergon.ch

 

Component: 
Airlock
Airlock Vulnerability Status: 
Airlock vulnerable, see resolution
Back-end Vulnerability Status: 
Airlock protects, requires changes in configuration