ITPro.TV: CompTIA Security+ (SY0-601)

CompTIA Security+ Exam Cram

Today I’m going to be reading through chapters 17 (Secure Protocols) and 25 (Public Key Infrastructure) of the CompTIA Security+ Exam Cram.

Secure Web Protocols

Remember: SSL/TLS is a transport layer security protocol (sitting between HTTP and TCP).

HTTPS was original developed by Netscape. TIL!

Apparently there’s an alternate standard called S-HTTP which was developed specifically for banking transactions. Based on Wikipedia’s summary, it looks like S-HTTP sent encrypted data (including an additional/alternative set of headers) in the request body, rather than wrapping the entire protocol in an encrypted channel (like HTTPS).

Exam Cram calls out Heartbleed explicitly, and notes that this vulnerability is closed in OpenSSL 1.0.1g and later.

HTTPS operates over stateful SSL connections.

TLSv1.0 succeeded SSLv3 in 1999. Note that TLS is not backwards-compatible with SSL.

TLS has two sub-protocols:

Types of DNS servers:

DNSSEC is designed to provide an authentication layer for DNS to prevent cache poisoning. DNS responses are signed in DNSSEC, and the keys used to sign those responses are themselves signed in a hierarchical fashion that parallels the arrangement for authoritative servers. For example, in DNSSEC, the response for www.example.com will be signed by example.com, the key used by example.com will in turn be signed by .com, and the key used by .com will in turn be signed by one of the root servers.

One reason DNSSEC is important is because DNS is increasingly used as a PKI: DANE (DNS-based Authentication of Named Entities) enables X.509 certificates used in TLS to be validated using DNS, SSHFP (SSH fingerprint posting) puts host fingerprints in DNS (what a great idea!), and DKIM is used to authenticate email.

Internet Protocol Security (IPsec)

IPsec is a network layer encryption protocol, and is commonly used as a VPN solution. IPsec uses the Internet Key Exchange (IKE) protocol for, well, key exchange.

Two modes:

IPsec in tunneling mode uses two headers:

IPsec headers immediately follow the header fields in an IP datagram. ESP can be nested in AH, which simplifies firewall filtering if you only require confidentiality for some connections.

The IKE protocol is part of the larger Internet Security Association and Key Management Protocol (ISAKMP).

Secure File Transfer Protocols

FTPS is to FTP what HTTPS is to HTTP (though there are additional complications since FTP is a two-channel protocol). FTPS uses port 990 for commands in implicit mode, and good old port 21 for commands in explicit mode.

SFTP is an entirely different beast - FTP-like functionality over SSH.

Note that FTPS, like FTP, requires multiple ports to function. This makes SFTP (which operates of port 22, like SSH) much easier to handle when configuring firewalls.

“Managed File Transfer” (MFT) services/applications allow FTP to be wrapped in a more secure protocol (HTTPS?) as well. These are popular in regulated industries.

Secure Email Protocols

Important ports:

S/MIME leverages MIME to provide authentication, message confidentiality and integrity, and nonrepudiation. S/MIME uses the “Cryptographic Message Syntax” to ensure the security of the underlying keys. Best practices dictate that separate S/MIME certificates be used for signing vs. encryption so that the encryption key can be escrowed without damaging non-repudiation.

Secure Internet Protocols

By default SSH tunnels are actually encrypted using IDEA (the International Data Encryption Algorithm) with a 128-bit symmetric key cipher that is agreed upon during the initial authentication/negotiation. Blowfish (32- to 448-bit keys), DES, and 3DES are also available. (Note that DES, and I suppose by extension 3DES, is still export-controlled.)

Lightweight Directory Access Protocol (LDAP)

There’s also LDAP-over-SSL (LDAPS), which again riffs off of HTTPS. As a total set of asides…

At the very least, LDAPS should be used when authenticating with Active Directory Domain Services (AD DS).

Secure Real-Time Transport Protocol (SRTP)

SRTP is similar to HTTPS in that keys must be exchanged before transmission begins, but is otherwise unlike HTTPS as it operates over UDP and applies the encryption to the protocol payload (rather than firing up an encrypted tunnel and then running an unencrypted protocol over it).

Simple Network Management Protocol (SNMP)

SNMP is used to collect statistics from devices over TCP/IP, and is typically used for monitoring equipment health (finally, an explanation for what SNMP is actually for!).

Individual devices run SNMP agents, which then send data to a “management station”. Data is sent via UDP 161 (polling) and UDP 162 (notifications). In SNMPv3 can alternately be run over TCP.

The only security in SNMPv1 is the “community name” (which functions like a password). This is set to “public” by default, and is seldom changed.

SNMPv2 introduced message integrity via MD5, but was still plaintext.

SNMPv3 supports both AES and 3DES, and represents a major rearchitecting of SNMP. It is the first version of SNMP that supports all three legs of the CIA triad, and does not use the “community” string.

SNMPv3 can be divided into the SNMP engine proper and a number of “applications” that run on top of the engine. Parts of the SNMP engine:

Defined SNMP applications:

Other vendor and custom-built SNMP applications are also allowed.

Using Network Address Allocation

The most basic security aspect of network design is the use of subnetting.

IP address classes:

Common reserved network blocks:

Note that, except for the Class A reservations, all of these use larger subnet masks than you would typically suspect. There are actually far more reserved blocks than just these four; Wikipedia has a good list.

CIDR (as in “CIDR subnet notation”) is “Classless InterDomain Routing”. This is the count of how many of the most significant bits are “masked” (held constant in the network).

IPv6 is a 128-bit address space (as opposed to the 32-bit address space of IPv4). IPv6 addresses are represented as eight groups of four hexadecimal digits (so each block represents 16 bits, exactly twice the size of an IPv4 block). The largest block consisting only of zeros can be replaced with :: (i.e., you can only use this trick once), and leading zeros in a block can also be dropped.

IPv6 also introduces the concept of “variable length subnet masking” (VLSM), which specifies subnets as needed rather than for the entire network. However, CIDR notation continues to work as you’d expect, so 2001:db8::/32 represents the subnet 2001:0db8:0000:0000:0000:0000:0000:0000 – 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff.

The IPv6 equivalent of 127.0.0.1 is ::1; the rest of the 127.0.0.0/8 block is replaced with the concept of “link-local” addresses, which are self-assigned per network interface addresses in the reserved fe80::/10 subnet (RFCs 7217 and 8064 defines how link-local addresses are assigned).

In both IPv4 and IPv6, the first address in a subnet represents the network itself, and the last address is used to broadcast to all devices on the network. These two addresses are thus unavailable for hosts to use.

Exam Cram notes that the Security+ exam will likely have questions related to identifying incorrectly configured subnets.

Using Time Synchronization

NTP operates over UDP. Time servers operate on a DNS-like hierarchy. The secure version of NTP is NTS (Network Time Security), which uses TLS + a second standard called “Authenticated Encryption with Associated Data (AEAD, which is used to extend integrity and authenticity guarantees to unencrypted header data). NTS only recently was submitted for publication as a standard.

Using Subscription Services

New acronym: “Anything” as a Service (XaaS, which probably actually stands for “X as a Service”). An umbrella term for all of the *aaS things.

PKI Components

A PKI should ideally provide the following:

Certificate Authorities (CAs)

A certificate authority (CA) is a trusted entity that issues certificates.

A registration authority (RA) sits between users and the CA, handling identity verification step.

Certificates issued by a CA are trusted in a transitive fashion, anchored in the CA’s “root certificate”. This allows CAs to themselves be arranged in a hierarchy.

Certification Practice Statement

The certification practice statement (CPS) is the legal document outlining the identity of the CA, the types of certificates it issues, the requirements it has for issuing these certificates, the CA’s operating procedures (issuing, renewing, revoking), and the security controls used in the process.

Not to be confused with certificate policies, which are the rules describing how a certificate may be used.

Trust Models

You could, of course, just have a single CA. Probably fine for a small or medium organization, but not a great idea in the real world.

More commonly, CAs are arranged in a hierarchy. CAs beneath the root CA in a hierarchy are called “intermediate CAs”. Because of their sensitivity, root CAs are normally entirely offline.

A variation of this is the “bridge CA model”, which uses hierarchies that are connected by cross-certifications with one or more “bridge CAs”. While a diagram of this looks like a hierarchical model, the difference is that the root CAs of the various hierarchies are using the bridge to trust each other, rather than obtaining their trust from the bridge. Thus a compromise of the bridge, while it would disconnect the various hierarchies, would not invalidate certificates issued by the actual root.

An alternative to a hierarchy is the “cross-certification model” - a.k.a., the “web of trust”. This model allows redundancy and a more realistic model of trust, but doesn’t scale well and is often difficult even for experts to work with.

Key Escrow

This is when the private half of a public/private keypair is held by a third party (which may or may not be the issuing CA) in addition to the user the key is issued to.

Escrow agents are not only able to read data encrypted by the public half of this key but also - because encryption capabilities are symmetric - are able to sign messages on behalf of the key user (harming nonrepudiation).

Key escrow is common in corporate environments. This both enables corporate access to employee data and allows for new user certificates to be quickly regenerated in the event of a lost password.

Digital Certificates

A “digital certificate” is a block of data used for identification purposes. Typically a certificate is signed by a CA’s private key, providing integrity and authenticity guarantees. Non-PGP certificates generally use the X.509v3 hierarchy, which contain the following (common) fields:

The inclusion of a public key within the certificate allows for encrypted communications to be safely bootstrapped (so, for example, the initial Diffie-Hellman key exchange can be encrypted in both directions).

Exam Cram indicates that it is likely the Security+ exam will require recognizing the parts of an X.509 certificate.

Public and Private Key usage

The X.509 standard does not support multiple keys, so if different keys are used for different purposes then multiple certificates must be exchanged.

Certificate Signing Requests

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.

Certificate Policies

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.

Certificate Types

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.

Certificate Formats

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.

Certificate Revocation

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

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.

Pinning

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).

ITPro.TV: CompTIA Security+ (SY0-601)

Secure Protocols

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.

Keys

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!).

PKI Concepts

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.

Certificates

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

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.