Certificates

More info on SSL certificates.

Also see SSLStrip and MITM Labs/Bettercap SSL Over Wifi

Basic HTTPS

Stripping SSL and sniffing HTTPS is not easy to do if the sheep is using a modern browser like Firefox or Chrome. These browsers will lock up when they detect invalid certificates:

Normal HTTPS Session

To understand why this happens, let's examine how a normal HTTPS session is supposed to go.

Client Request: First, the client sends an HTTPS request to the HTTPS web server.

Server Response: The server responds with its certificate. This is equivalent to a public key that the client uses to encrypt communications with the server.

Client Key: The client responds with its public key, which the server will use to encrypt communications with the client

Each party has a private key, which they combine with the other party's public key, to encrypt their communications. (How does it work? THE MATHS - SPECIFICALLY ZETA FUNCTION MATHS)

The end result: secure, encrypted communications established by exchanging only public information on a public channel.

MITMed HTTPS Session

When an HTTPS session is attacked with a man in the middle attack, the modified sequence looks like this:

Sheep Request (intercepted by attacker): First, the sheep sends an HTTPS request to the HTTPS web server, which is intercepted by the bettercap HTTPS proxy.

Fake Server Response: The attacker responds to the sheep with its (self-signed) certificate. This certificate, equivalent to a public key, is an identity mechanism - cryptographic fingerprint of the HTTPS proxy server.

(Aside: This public key corresponds to one and only one private key that is a cryptographic, identifying fingerprint - that's a symbol of everyone's trust in your identity. To create a public/private key pair that looks exactly like EvilCorp.com's, for example, and that would allow an attacker to completely and transparently pwn all https://evilcorp.com visitors by assuming the identity of the corporation and masquerading as them, one would need to obtain Evil Corp's private key - their cryptographic identity - no easy task.)

Attacker Request Forward: The attacker forwards the original HTTPS request to the HTTPS server, which is unaware of the MITM attack.

Server Response (intercepted by attacker): The server responds with its certificate. This is the public key that the attacker uses to encrypt communications with the server (which is still unaware of the MITM attack).

Client Key: The client responds to the attacker's (self-signed) certificate with its own public key, so that it can communicate securely with the attacker (which it thinks is the trusted HTTPS web server).

The end result: the attacker has established secure, encrypted communication channels with the sheep and the server.

Detecting the Attack

The naive may think this is enough to thwart encryption. But there's an alternate channel here for verifying identity: the public key. If the domain and the public key do not match, the sheep knows the traffic is being tampered with and that it is being presented with a fake certificate.

Responsibility to detect HTTPS MITM attacks falls on the sheep's browser. The browser should be checking the public keys of each certificate it receives with the domain of the certificate. If the two do not match, then the encryption channel that has been established is hazardous and links to an attacker, not to the trusted endpoint.

For the attacker to truly trick the sheep into trusting it, it would need to find a private key of Evil Corp - which, given that it is equivalent to Evil Corp's digital identity, is going to be a closely-guarded secret that is impossible for the armchair pentester to crack.

Alternatively, you hijack the trust mechanism of the sheep's browser (pop up from Level 3 to Level 7).

Bettercap Command

Add the --proxy-https flag to enable an HTTPS proxy and redirect all HTTPS requests to it.

$ bettercap -I wlan0 -O bettercap-https.log -S ARP -X --proxy-https --gateway 192.168.0.1 --target 192.168.0.7