As per the researchers: ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. Attackers can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.
Analysis: The generic attack requires a MitM attacker that can intercept and divert the victim's traffic at the TCP/IP layer.The attacker needs to have some way of intercepting and modifying the data sent from the victim’s browser to the web server. This is difficult on the Internet, but can be a plausible attacker model on the local network. The more dangerous variation of this attack requires the victim to use Microsoft Internet explorer and therefore Linux users are generally not vulnerable to them. How the attack works: The ALPACA attack is only possible because TLS does not protect the source or destination IP and port address of the TCP connection. As is stated in the TLS RFC, TLS is application layer independent. However, this gap in protection gives the attacker the flexibility to redirect traffic from one server to another, making the cross-protocol attack possible. Basic idea behind application layer cross-protocol attacks on HTTPS. A MitM attacker leads the victim to an attacker-controlled website that triggers a cross-origin HTTPS request with a specially crafted FTP payload. The attacker then redirects the request to an FTP server that has a certificate compatible with the web server. The attack either (1) uploads a secret cookie to FTP, or (2) downloads a stored malicious JavaScript file from FTP, or (3) reflects malicious JavaScript contained in the request. In case (2) and (3), the JavaScript code is executed in the context of the targeted web service. Conditions required for the attack to work: 1. As per mentioned above you need a MiTM atack who can divert victim's traffic at the TCP/IP layer and therefore the only plausible attack model is on the local network. 2. If you are hosting several TLS-enabled application servers on the same hostname, or if you use multi-domain certificates, or if you use wild-card certificates, you may be vulnerable to the general confusion attack.
Created vsftpd tracking bugs for this issue: Affects: fedora-all [bug 1975648]
vsftpd: This issue was fixed in v3.0.4 via the following changes: - Close the control connection after 10 unknown commands pre-login. - Reject any TLS ALPN advertisement that's not 'ftp'. - Add ssl_sni_hostname option to require a match on incoming SNI hostname.
Created dovecot tracking bugs for this issue: Affects: fedora-all [bug 1975652] Created exim tracking bugs for this issue: Affects: fedora-all [bug 1975653] Created nginx tracking bugs for this issue: Affects: fedora-all [bug 1975651] Created sendmail tracking bugs for this issue: Affects: fedora-all [bug 1975650]
nginx: Fixed in v1.21.0 via the following commit: http://hg.nginx.org/nginx/rev/ec1071830799
Postfix: As per the researcher: Postfix implements a detection for HTTP requests as well as HTTP headers. As soon as a command contains an HTTP status line or a key-value pair separated by a colon, the server will immediately terminate the connection. Therefore it is resistant to this attack.
Sendmail: "Sendmail only detects HTTP requests at the very start of a connection. If STARTTLS is used, the first command inside the connection can bensent by the attacker, bypassing the detection" Sendmail fixed a bug to detect HTTP requests when STARTTLS is used in 8.16 As per the release notes: SECURITY: If sendmail tried to reuse an SMTP session which had already been closed by the server, then the connection cache could have invalid information about the session. One possible consequence was that STARTTLS was not used even if offered. This problem has been fixed by clearing out all relevant status information when a closed session is encountered.
Dovecot: POP3.All POP3 servers were tolerant towards HTTP request and header lines.Dovecot POP3 implements a counter that resets after valid commands. However, with only three consecutive errors allowed, and the restrictions of the POP3 protocol, it seems highly unlikely that an attacker can bypass the error limit by inserting attacker-controlled header lines to reset the counter.As for reflection, Dovecot POP3 allows XSS reflection only post-authentication using an unknown command. For all other POP3 servers we could not find any reflection vectors. Therefore dovecot is not affected.
Analysis is complete for Ansible and it was found that Ansible is using the vulnerable version of nginx i.e. v1.16.1. Required trackers have been created.
Hello @huzaifas, if I do not use wildcard certificates or multi-domain certificates but certificates that are valid wrt CA but not valid wrt hostname verification, is this issue applicable?
(In reply to Satish B from comment #37) > Hello @huzaifas, if I do not use wildcard certificates or multi-domain > certificates but certificates that are valid wrt CA but not valid wrt > hostname verification, is this issue applicable? If you are a Red Hat customers, I would urge you to please contact Red Hat support. Thank you