Diffie-Hellman and Forward Secrecy
The X.509 standard does not support multiple keys, so if different keys are used for different purposes then multiple certificates must be exchanged.
A certificate signing request (CSR) is just a structured request to a CA to generate a digital certificate, including the information required for that certificate (as well as anything else the CA requires). CSRs are signed by the private half of the included public key.
The rules indicating how a certificate may be used. While the certificate policies are distinct from the certification practice statement (above), there can also be a lot of overlap (for example, renewal policies). The key here is that the certification practice statement describes the CA’s practices as a whole, which the certificate policies apply only to the certificate being issued.
For server TLS certificates:
Browser used to treat these three types of certificates differently (for example, by displaying the business name in the URL bar for EV certificates), but this is no longer commonly done.
Other types of certificates:
Code signing implementations are kind of wild, and not always in good ways.
Certificates can be binary of base64 encoded. Common formats:
PEM stands for “privacy enhanced mail”, and is the most common format. PEM files can actually contain multiple certificates and private keys, separated by BEGIN CERTIFICATE / END CERTIFICATE and BEGIN PRIVATE KEY / END PRIVATE KEY specifiers (each specifier is preceded and followed by -----
). The .key extension is also sometimes used for PEM files, but only when the file contains a single private key.
The PKCS#7 key format looks superficially similar to PEM, but uses the BEGIN PKCS7 / END PKCS7 specifier (again preceded and followed by -----
).
DER stands for “distinguished encoding rules”.
PFX stands for “personal information exchange”. Like PEM, multiple certificates and private keys can be stored in a single .p12 file.
Revocation occurs when a certificate is invalidated before its expiration date. Revocations can be communicated in one of two ways:
Certificates can also be “suspended”, which is a state that indicates it is under investigation for revocation. While a suspended certificate may remain in place, it is not valid for any uses.
OCSP stapling involves the web server providing OCSP validity information as part of the TLS handshake. To perform stapling, the web server does the following:
OCSP stapling tries to work around the problem of clients failing open when no OCSP response is returned, though the solution is incomplete (a malicious party that can potentially strip both the stapled OCSP response and block the client OCSP requests). It does resolve the privacy and load issues of the original OCSP implementation, however.
While Exam Cram’s assertion that certificate pinning exists to thwart man-in-the-middle attacks is technically true, I think it misses the broader picture of how weak the CA system has turned out to be in practice (if the CA system worked correctly, man-in-the-middle attacks on SSL connections would be much harder).
The TLS handshake:
This encrypted shared secret then becomes the basis of the shared session key(s). (There are really two keys - an HMAC key which verifies the validity of the session key, and the session key itself.)
(When using ephemeral Diffie-Hellman to derive a rotating session key, we don’t actually encrypt anything with the server’s public key in the last step, nor do we use the two exchange random numbers. Instead, the server picks Diffie-Hellman parameters p
and g
, and sends those along with its own derived public key. Importantly, the server also signs this message, preventing it from being tampered with. The client then uses p
, g
, and its own secret to produce a public key, which it sends to the server. The encrypted connection established, the first thing that the client and server send are hashes of the initial handshake messages to verify the integrity of the initial negotiation… Though I think as of TLSv1.3 this hash exchange may be largely vestigial?)
Important ports:
(Dan Lowrie states that scp is considered deprecated now… Which surprisingly turns out to be true! Though there’s apparently a version of scp that’s actually sftp under the hood in development, so the end impact of this deprecation will probably be close to zero.)
SRTP: Secure Realtime Transport Protocol.
SNMP handles not just reporting, but also device configuration. Only SNMPv3 has encryption and authentication.
Cryptographic Service Provider: The algorithm used to generate an encryption key (AES, etc.).
Note that RSA defines both a type of public/private keypair and a key exchange algorithm. In fact, that key exchange algorithm was the standard in SSL/TLS up until TLSv1.3 (when all key exchange methods except those based on ephemeral Diffie-Hellman were removed) - it’s the algorithm that uses the two random numbers exchanged during the initial negotiation to generate a (symmetric) session key!
Key stretching is primarily used to increase the effective length of encryption passwords (that are then used to derive keys). Important key stretching algorithms:
Both of these are about using salts + multiple hashing rounds.
The most popular key derivation protocol is probably ECDHE at this point, as it is both fast and secure (a seldom-seen combination!).
OCSP: Online Certificate Status Protocol.
Active Directory’s PKI infrastructure is called “Active Directory Certificate Services”.
The “Online Responder” role forAD Certificate Services handles OCSP requests.
“Enterprise CAs” integrate with AD, while “Standard CAs” don’t.
Typically, root CAs have longer keys than subordinate CAs, which have longer keys than user/entity keys. Root CA keys also generally have much longer validity periods than intermediate CA or user/entity keys.
Root CA certificates are self-signed by default, though in a bridged PKI system they will also be signed by the bridge CA key.
Important types:
Certificate formats:
PKCS#12 is generally used for backing up CAs, while PKCS#7 is used for normal key exchange. Both of these are (almost exclusively) used by Windows.
IPSec: Internet Protocol Security. Not really a single protocol - more a family of inter-related protocols.
IPSec is primarily used as a VPN solution (both site-to-site/gateway-to-gateway and client-to-gateway).
IPSec is built on a number of components, the most basic of which is the “Security Association” (SA) - trust relationships between endpoints (could be client-to-client, client-to-gateway, or gateway-to-gateway).
(IKE) Phase 1 SA (“main mode”) doesn’t actually set up an IPSec connection, but instead negotiates a single encrypted bidirectional tunnel between the endpoints. The negotiation consists of:
The phase 1 tunnel is then used to set up the (IKE) Phase 2 SA (“quick mode”), which establishes two unidirectional encrypted tunnels between the endpoints. In phase 2, the negotiation consists of:
Note that the only data sent over the phase 1 connection is the configuration information necessary to set up phase 2 - all actually point-to-point communications happen via the phase 2 tunnels.
Every security association has an identifier (which is invalidated after the session is over), and packets are sequenced as well. This provides two layers of protection against replay attacks.
There are two IPSec “protocols”:
These protocols can be used independently or together. The main reason to mix-and-match is if you are using encryption (which requires ESP) for only some connections on your network. Since AH is partially duplicative of ESP, by using both (and turning off the overlapping capabilities in ESP) you can ensure that all IPSec packets use AH with only a small increase in the overhead of packets using ESP. This allows for (modestly) simpler firewall rules.
There are also two IPSec encapsulation methods used by ESP:
The distinction makes sense when you consider that tunnel mode is joining two existing networks, while transport mode is joining two individual machines on the “same” network. You could imaging using tunneling mode in place of transport mode, but then the new header would be (functionally) the same as the original header; thus, there is no security benefit to encrypting the original header in this situation. The extra “translation” step between the gateways is why encrypting the entire original packet makes sense.
Additionally, IPSec tunnels are built using either PPTP (the point-to-point tunneling protocol) or L2TP (the layer 2 tunneling protocol). Note, however, that only L2TP is considered secure.
IKE occurs over the Internet Security Association and Key Management Protocol (ISAKMP), which is how its tagged in Wireshark.