Q:

Does HTTPS protect against active attackers?

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?

A:

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:

Authentication of the server (so an attacker cannot present their own public key and get the client to accept it as the valid one).
Encryption of the data transferred in both directions (thus providing confidentiality, as you noted).
Integrity of the message text (to prevent bit-flipping attacks on the ciphertext, for example).
Replay protection (capturing encrypted traffic from one part of the conversation and injecting it into a later part will not work).
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.

