Certificates

This page contains information about SSL certificates for establishing secure lines of communication with public servers.

You can obtain your own certificates, and even forge new ones, and serve them up using SSLStrip and a man in the middle attack. See MITM Labs/Bettercap SSL Over Wifi

Alternatively, if you are unable to forge a private key for a certificate, you can always take the easier route of obtaining a private key for the sheep, and eavesdropping that way. See MITM_Labs/Decrypting_HTTPS_Traffic_with_Stolen_Private_Key.

Code Signing Certificates

Whoops, wrong page. Check Code Signing Certificates.

Basic HTTPS

With HTTPS attacks having been in the wild for 15 years, and browser technology constantly evolving, protection against HTTPS attacks has definitely improved over the past 15 years (Moxie Marlinspike originally presented sslstrip/sslsniff at Defcon 9: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf). For this reason, stripping SSL and sniffing HTTPS is not easy to do if the sheep is using a modern browser like Firefox or Chrome. Many sites insist on HTTPS, making it impossible to strip SSL out. Modern browsers will also 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).

Defeating HTTPS with sslsniff and fake certificates

To defeat HTTPS in a way that is transparent to the sheep, you must be able to issue a certificate that the sheep trusts, and obtain a private key for that certificate. sslsniff allows you to use various self-made certificates and serve them up for various domains. This makes it easy to automate dealing with large numbers of forged certificates.