A hacker can send data to a mail server to interfere with an HTTPS connection

When accessing a service over a protected HTTPS connection, the browser does not pass data to the Web server until the Web site's digital certificate has been verified. The scheme prevents man-in-the-middle attacks that monitor/tamper with data, and prevents users from being collected with authentication cookies or running malware on a victim's device. However, Ars Technica reports that a recently revealed hack method shows that attackers can still trick browsers into connecting to Email/FTP servers that use compatible certificates, posing a corresponding risk.

Because the domain name of a Web site matches the domain name in an E-mail or FTP server certificate, browsers will often connect Transport Layer Security (TLS) to one of these servers, rather than the site the user intended to visit.

When your browser communicates using HTTPS, but your Email/FTP server communicates via SMTP/FTPS or some other protocol, you are likely to experience serious errors.

Such as sending decrypted authentication cookies to an attacker, or executing malicious code on a victim's machine.

Far-fetched as it may sound, a new study shows that this kind of attack is possible.

About 1.44 million Web servers use domain names that are compatible with the encrypted credentials of Email/FTP servers from the same organization.

Some 114,000 of these sites are considered vulnerable because Email/FTP servers use software that is known to be defective.

TLS, the bedrock of Internet security on which millions of servers rely, encrypts data as it travels between the end user and the server, ensuring that no one can read or tamper with the connection.

Still, in a study published Wednesday, Dr. Brinkmann and seven other researchers delved into whether so-called cross-protocol attacks could be used to bypass TLS protections.

The known problem is that Transport Layer Security (TLS) does not protect the integrity of a TCP connection, but only the use of HTTP, SMTP, or other Internet servers. The main components of the attack are:

(1) Client application used by the target end user -- here C;

(2) currently intend to access the server -- Sint for short;

(3) Proxy server, a computer connected via SMTP/FTP/or using a different protocol from ServerInt, but with the same domain in its TLS certificate.

Even if the middleman (MITM) cannot decrypt TLS traffic, an attacker can still achieve other goals -- such as forcing the target browser to connect to an Email/FTP server (rather than the intended Web server).

This can cause the browser to send authentication cookies to the FTP server, exposing the vulnerability of cross-site scripting attacks and allowing the browser to download and execute malicious JavaScript scripts hosted on the Email/FTP server.

Thankfully, the flaw, which the researchers call the Application Layer Protocol Allowing Cross-Protocol Attacks (ALPACA), won't pose a significant threat to most people for a while.

However, there is still the possibility of increased risk if new attack routes or vulnerabilities emerge, or TLS is used to protect other communication schemes.