最後更新: 2021-02-25
dh 說明
dh = Diffie Hellman key exchange
A method of securely exchanging a shared secret key over an insecure public channel
dh key file 是可以公開的 (Public information)
The shared secret key can then be used to encrypt subsequent communications
using a symmetric key cipher.
* required for --tls-server only (在 client conect 上 server 時就會獲得此 file)
DH parameters that consist of two numbers p (a large prime number) and
g (the generator value, which is always 2 for OpenSSL)
運作
Alice and Bob wish to communicate
1
They first agree between them a large prime number p, and a generator g (where 0 < g < p)
2
Alice chooses a secret integer a (her private key) and then calculates ga mod p (which is her public key).
Bob chooses his private key b, and calculates his public key in the same way.
3
Alice and Bob then send each other their public keys.
A "g^a mod p"> B
A < "g^b mod p" B
4
因為 (g^a)^b mod p = g^(ab) mod p 所以他們有 shared secret key
5
In ephemeral-static mode one party will generate a new private/public key every time,
thus a new shared secret will be generated.
CLI
# 產生一個 2048 bit 的質數
openssl dhparam -out dh2048.pem 2048
#查看 key 的 info
pkeyparam - Public key algorithm parameter management.
openssl pkeyparam -in dh2048.pem -text
-----BEGIN DH PARAMETERS----- ... -----END DH PARAMETERS----- DH Parameters: (2048 bit) prime: 00:94:df:9d:fb:05:3b:f3:51:2f:ef:48:55:20:0f: .. generator: 2 (0x2)
The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and eventually acquires the private key, he can use that to decrypt the session key from SSL exchange, and then use that to decrypt the whole session. So that's not perfect forward secrecy.
The key here to Perfect Forward Secrecy is the Diffie-Hellman key exchange. DH is a very cool algorithm for generating a shared key between two parties such that an observer who sees everything -- the whole exchange between the two parties in the clear -- cannot derive the key just from what is sent over the wire. The derived secret key is used one time, never stored, never transmitted, and can never be drived ever again by anyone. In other words, perfect forward secrecy.
DH alone can't protect you because it's trivial to play man-in-the-middle as there's no identity and no authentication. So you can continue to use RSA for the authentication and just use Diffie-Hellman to generate the session key. That's DHE-RSA-*, so for example: DHE-RSA-AES128-SHA1 is a cipher spec that uses Diffie-Hellman to generate the key, RSA for authentication, AES-128 for encryption, and SHA1 for digests.
But Diffie-Hellman requires some set-up parameters to begin with. These aren't secret and can be reused; plus they take several seconds to generate. But they should be "clean", generated by you so you know they're not provided by an attacker. The dhparam step generates the DH params (mostly just a single large prime number) ahead of time, which you then store for the server to use.
An interesting bit is that Elliptic curve Diffie–Hellman is a modified Diffie-Hellman exchange which uses Elliptic curve cryptography instead of the traditional RSA-style large primes. So while I'm not sure what parameters it may need (if any), I don't think it needs the kind you're generating.
I don't have all the answers here, but I'll keep looking and update this answer when I know more.
Perfect Forward Secrecy
Prime-field groups (EDH):
The server needs to be configured with a suitably-large prime and a corresponding "generator".
The acronym for forward secrecy over prime fields is EDH for Ephemeral Diffie-Hellman (also abbreviated as DHE).
Elliptic-curve groups (EECDH):
The server needs to be configured with a "named curve".
These offer better security at lower computational cost than prime field groups, but are not as widely implemented.
The acronym for the elliptic curve version is EECDH which is short for Ephemeral Elliptic Curve Diffie-Hellman (also abbreviated as ECDHE).
Elliptic curves used in cryptography are typically identified by a "name" that stands for a set of well-known parameter values,
and it is these "names" that are used in the TLS protocol.
# Get openssl Ciphers support PFS
All ciphers that support forward secrecy have one of five values for the first component of their OpenSSL name: "AECDH", "ECDHE", "ADH", "EDH" or "DHE".
Ciphers that don't implement forward secrecy have names that don't start with one of these prefixes.
openssl ciphers -v \ 'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' | awk '{printf "%-32s %s\n", $1, $3}'
TLS 1.3 always uses forward-secrecy.