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?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
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:
Some cipher suites provide additional protection:
TLS (including HTTPS) can be optionally configured to provide the following protection:
TLS does not provide the following protections:
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.
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.