Does HTTPS protect against active attackers?

Question

I know that HTTPS protects against passive attackers, due to encryption. Which of course provides confidentiality.

So does it protect data(passwords, emails, etc) during traffic, against active attackers? If so, how?

Answer 1

TLS (the secure network protocol underlying HTTPS) specifies a large number of "cipher suites" (combinations of cryptographic primitives, like asymmetric and symmetric ciphers, hash functions, etc.). All widely-used cipher suites - the only ones that should be permitted either by clients such as web browsers, or by servers - provide the following:

1. Authentication of the server (so an attacker cannot present their own public key and get the client to accept it as the valid one).
2. Encryption of the data transferred in both directions (thus providing confidentiality, as you noted).
3. Integrity of the message text (to prevent bit-flipping attacks on the ciphertext, for example).
4. Replay protection (capturing encrypted traffic from one part of the conversation and injecting it into a later part will not work).
5. Sequence protection (an attacker cannot successfully take multiple message packets, rearrange them, and transmit the reassembled message; it will be rejected)

Some cipher suites provide additional protection:

• Perfect Forward Secrecy (PFS), such that even if an attacker records a conversation and later gains access to the server's private key, the conversation can never be decrypted (save by brute force or breaking the cryptographic primitives).

TLS (including HTTPS) can be optionally configured to provide the following protection:

• Authentication of the client (normally, the server supplies the client with a certificate showing the server's authenticity; it is possible for the client to also supply the server with such a certificate, which can replace the need for other forms of authentication such as transmitting a password).
• Downgrade protection, preventing fallback to older protocol versions with known or suspected vulnerabilities.

TLS does not provide the following protections:

• Length masking, beyond the limited degree provided by some primitives (if the attacker knows the lengths of the possible messages in either direction, and each possible message has a different length, the attacker can probably reconstruct the message traffic by watching message lengths).
• Timing masking, beyond adding some overhead (if the attacker knows how long certain operations take, the attacker can guess when those operations have been requested / performed by monitoring the times between messages in each direction).
• Availability (a man-in-the-middle can always just decide not to pass on the network traffic, resulting in denial of service).
• Client or server anonymity (the client IP address, and the server's IP address and host name, are exposed in plain text to anybody monitoring the traffic).

In general, yes, HTTPS is secure against most active attacks aside from denial-of-service. However, there are limitations. TLS does not protect against exploitation of weaknesses in the cryptographic primitives it uses (for example, this is why cipher suites using the RC4 symmetric cipher are now deprecated). Its encryption leaks side-channels such as length and timing, which in some applications may enable an attacker to break the confidentiality (although a security-conscious application could normalize the lengths / timings of network traffic to close this side-channel).

Additionally, it possible to use TLS insecurely if you configure it wrongly. For example, certificate authenticity validation checks can be disabled or replaced with incorrect custom checks, invalidating the authentication check and allowing an active attacker to use a fraudulent certificate. If both client and server permit insecure ("NULL") cipher suites, it is possible to configure TLS to use no authentication, encryption, or integrity checks. Finally, TLS implementations themselves may have security vulnerabilities. The "Heartbleed" vulnerability of 2014 was due to a extremely severe security bug in a very common TLS library (OpenSSL); if insecure / unpatched implementations are used, the protections of TLS may be bypassed and/or other weaknesses may be introduced.

Answer 2

I would say it depends on the type of active attack and the intent of the attacker ... if this is a Denial of service attack for example, then HTTPS will not really protect you here ... but if the intent is to get access to private data, then HTTPS is a good FIRST line of defense to have:

For example, say you want to login to a bank website, the site asks for your username and password. When submitting this data, you do not want it transferred in clear text right, so one way the app protects you is use HTTPS technology to "hide" this data in plain-sight (encryption) as it is sent to the bank for verification. And once the bank receives it, it knows how to "un-hide" it back to your credentials and log you in. Then the bank server will issue an identifier/session to help track you as you move in between the web pages in the app. The bank needs a way to share/send you this session/identifier. And we do not want an eavesdropper to get this identifier/session or guess it, and so encryption is used to hide it in plane sight again and send it to you. I'm simplifying here of course, but that's the idea. And that's one way HTTPS is can protect you from an attacker.

HTTPS is by no means the only defense you should have against attackers. You need more than that, for example, you need to protect your system against authorized users, XSS, SQL injection etc.

This also depends on what you are trying to protect. This is a good question, but it can be answered in many ways as it "depends" on a number of things.