TLS
TLS is a protocol that uses multiple types of security algorithms to provide confidentiality and integrity over TCP. TLS is a connection layer with a handshake providing key exchange using certificates, message authentication and encryption.
IETF TLS has evolved from OSI X.509 and Netscape SSL. SSL is dead (r.i.p. 1999), long live TLS
| Do Not Use | Can be used | Recommended | |
|---|---|---|---|
| TLS Versions | SSLv2, SSLv3 | TLSv1.0 (do not use compression), TLSv1.1 | TLSv1.2, TLSv1.3 |
| Key exchange | Anonymous DH, export Grade, DSA | ||
| Asymmetric Key pairs | RSA < 829, ECC < 224 bits | RSA (use 2048 bit keys or higher) | ECDHE, secp256r1 |
| Integrity Hash | MD2, MD5, SHA-1 | SHA-256, SHA-384, SHA-512 | Poly1305, SHA-3 |
| Block Ciphers | RC2, RC4, DES, Idea, Blowfish, 3DES | AES, Camellia, ChaCha20 | |
| IV Random Generator | Dual_EC_DRBG | RSA-2048, ECDHE | |
| Block mode | ECB | CBC, CTR | GCM |
Use at minimum: TLSv1, RSA-2048 or ECDSA-256, AES-128-CBC, SHA-256
Use preferably: TLSv1.3, SHA-512, ECDHE, AES-256-GCM or better, TLSv1.3, SHA3, EC
Links
https://ciphermachinesandcryptology.com/
https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/
https://access.redhat.com/articles/3642912
https://www.youtube.com/watch?v=kAaIYRJoJkc
https://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html
Organization certificate steps
1. Appoint a responsible for creating and managing private key and guard it is a business critical secret. A RSA should be a 4096 bit key. Encrypting the key makes starting up webservices difficult
2. Create a CSR certificate signing request. The Subject:CN=www.domain.com is the URL the certificate is valid for. Use SNI or wildcard certificates when you need to protect multiple domain names.
3. Optionally change the certificate format (PEM / PKCS) depending on the application needing the certificate.
4. Install the certificate, intermediate and private key on the webserver.
5. make sure the ownership of the private key is readable by a restricted user like root.
6. Adjust the ciphers offered by the webserver, No RC4 or 3DES and no SSL only TLS1.0 and higher.
7. Scan with ssllabs.com what the rating is and fix the findings.
8. Monitor your certificate expiry and replace it before it expires
Confidentiality and Integrity
Secure protocols provide Confidentiality and Integrity.
• Confidentiality (encrypt/cipher) provides protection against data from being read by an unauthorized party. When Alice sends a message to Bob, encryption prevents others without the key to read the message.
• Integrity (signing/hash/digest) provides the possibility to verify the sender. When Alice sends a signed message to Bob. Bob can verify that the message really came from Alice and not from Eve. Eve can still read the message.
Integrity Hashing
Certificate private key signed with only SHA1 are marked as insecure by browsers and should be replaced by SHA256 signed certificate.
Certificates contain a public key which is signed an integrity hash. Chrome, IE, Firefox, Java dropped support for SHA-1 signed certificates in 2016. SHA-1 is from 1995 and the stronger SHA-2 and SHA-3 already exist. An SHA-1 hash collision can be found by padding a document (http://shattered.io/).
In January 2020 a chosen prefix attach https://sha-mbles.github.io/ was published.
Root certificates are shipped with browsers so those are still considered safe anchor points, but the certificates that are negotiated like intermediate certificates and normal certificates, should not be signed with SHA-1 and browsers will drop support by 2017, but you might get complaints sooner from for instance Chrome.
Keccak won the NIST competition (Aug 2015), now subset referred to as SHA-3
Below are two pictures on how MD5 and SHA-1 process one round on 32 bit words. In MD5’s 64 rounds, A’ is calculated as function of A with B,C and D and the result is rotated and repeated.
MD5 and SHA-1 have been deprecated and newer SHA-2 and SHA-3 use more rounds and bigger blocksizes that result in longer hashes, with less chance of collisions.
https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions
MD5
1992 as RFC 1321
- In 1996, a full collision was reported, and cryptographers recommended replacing MD5 with a different cryptographic hash function such as SHA-1.
- Early in 2004, a project began to prove that MD5 was vulnerable to a birthday attack due to the small size of the hash value at 128-bits.
- By mid-2004, an analytical attack was completed in only an hour that was able to create collisions for the full MD5.
- In 2005, a practical collision was demonstrated using two X.509 certificates with different public keys and the same MD5 hash value. Days later, an algorithm was created that could construct MD5 collisions in just a few hours.
- A year later, in 2006, an algorithm was published that used tunneling to find a collision within one minute on a single notebook computer.
- In 2008, MD5 was officially declared “cryptographically broken” as MD5 hashes can be created to collide with trusted X.509 certificates issued by well-known certificate authorities (CAs).
HMAC
Encrypt the hash with a common/shared key.
AES Challenge Response
Sign
Encrypt a hash with the senders private key. The receiver can use the senders public key, to prove the message came from the sender.
Asymmetric v.s. Symmetric ciphers
Key Exchange uses asymmetrical encryption with a private and public key pair. The public key can be freely shared and is used for encryption. The private key has to be kept secret. Only a party with the private key can decrypt the message. The public key can be placed inside a certificate and only the holder of the private key can decrypt a challenge message and prove they own the private key.
A symmetric session key can be exchanged which is the same for encrypting and decrypting. This is less computational intensive.
The data is transmitted using symmetric encryption in data blocks. The first block is mixed with a shared initial vector (random) and encrypted with a shared secret key. This block is than used as input for the encryption of the next blocks. With the message authentication (integrity) the receiver can verify the message is not altered.
- key agreement and key distribution.
- hash functions
- message authentication codes.
- signature schemes
- Symmetric ciphers (shared key)
- block ciphers (and modes of operation)
- stream ciphers
- Asymmetric ciphers (public private key pair)
Asymmetrical public key encryption like RSA, DSA or elliptic curve derived algorithm like ECDSA or ECDHE are computational intensive. Asymmetrical public/private key pairs are used to exchange symmetric shared secret keys.
https://www.youtube.com/watch?v=ncL2Fl6prH8 (The Enigma Code)
- Asymmetric primitives
- public key encryption
- public key authentication/identification schemes
- key encapsulation mechanisms
Until 2001 U.S. companies were not allowed to export strong encryption and have used deliberately weak export grade encryption by reducing the key length. These should be avoided. Anonymous key exchange should also be avoided.
For RSA and DSA use at minimum 2048 bit keys, but preferably 4092 bit. For ecliptic curves, avoid using P-256 and use Curve25519 instead. https://safecurves.cr.yp.to/
https://en.wikipedia.org/wiki/Modular_exponentiation
Symmetric Ciphers
For streams of data symmetric ciphers like AES are used. With symmetrical ciphers the same key can encrypt and decrypt blocks of data. The first blocks of data is mixed with a random IV and the next blocks are mixed with results from the previous blocks in a chain. Symmetric keys are negotiated using protocols Symmetric ciphers use the same key encrypting and decrypting. Ciphers with less than 128 bit key length are weak, like RC4, Blowfish, IDEA and DES and 3DES, they can be broken. Modern ciphers are AES, Camellia, ChaCha20 and less common Aria and Seed
Feistel / Lucifer / DES
Horst Feistel was a researcher at IBM, published the Feistel network (1971) which resulted in the Lucifer cipher (1973) and its successor the DES cipher (1975)
3DES Cipher
NIST FIPS initially selected DES as approved cipher for use by US governments. DES uses a 56 bit key, 8 bits are padding. The short keylength of 56 bit keys can be brute forced. To make DES stronger 3DES, TDES, Triple-DES (1998) is used to do DES encryption 2 or 3 times. The third round uses the same key as the first round, so the effective keylength is 112 bit. With enough computing power, it’s feasible to brute force 3DES.
AES Cipher
Rijndael was submitted by Joan Daemen and Vincent Rijmen from the University Leuven in Belgium for the NIST competition. In 2001 NIST (FIPS 197) selected Rijndael as AES Advanced Encryption Standard. Similar competitions have also selected AES are CRYPTREC (Japan) and NESSIE (EU)
In 2013 EU ECRYPT II has evaluated encryption strength.
http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf
http://bench.cr.yp.to/results-sign.html
AES has a key length of 128, 192 or 256bit AES does 10 rounds of 4 transformations • ByteSub (S-Box Transformation) • ShiftRow • MixColumn • AddRoundKey
A visual description of how AES works can be seen here.
https://www.youtube.com/watch?v=mlzxpkdXP58
AES operations are done on 128 bit blocks. Block chaining uses an initialization vector (IV) to introduce randomness to encrypted form. ECB block chaining should not be used, because the encrypted blocks still reveal the contours of the original message.
ECB reuses the IV and although the message is encrypted, the pattern is still visible. CBC (1976) doesn’t have this problem, it uses the output of the previous block as input to the next block. CBC is simple and often used. GCM Galois/Counter Mode (2007) uses multiple blocks in counter mode and is stronger than CBC and is implemented in hardware. Modern hardware implement instructions to speed up AES (intel AES-NI) or SHA-256/SHA-512 (intel AVX1/AVX2, RDRAND and RDSEED) e.g. PCLMULQDQ for GCM e.g. SHA256MSG2 for SHA https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni Intel has hardware acceleration for encryption built-in processors, the feature flags are MMX,SSE2,XMM6 https://software.intel.com/sites/default/files/article/402097/intel-sha-extensions-white-paper.pdf https://wiki.alpinelinux.org/wiki/Custom_Kernel CAMELLIA -- avx2, avx, aes-ni CHACHA20 -- avx2, neon CAST5 – avx CAST6 – avx TWOFISH – avx SERPENT -- avx2, avx, sse2 SHA1 -- avx2, ssse3, neon, spe SHA2 -- avx2 SHA256 -- ssse3, neon, spe SHA512 -- avx2, ssse3, neon POLY1305 -- avx2 GHASH -- pclmulqdq (part of aes-ni), vmx (power8) AES -- aes-ni, neon, vmx (power8), spe CRC32 -- pclmulqdq, sse, neon, vmx (power8) CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8) Brute force, side-channel attacks, some rounds broken, still secure
Hashing MD5 and SHA1 are broken. Use SHA-2 (SHA256, SHA384 or SHA512) or SHA-3. Hashing algorithms use mathematical one-way transformations, where chunks of data are shredded to a fixed length hexadecimal string. This operation is repeatable and always will have the same result, but from a hash it’s impossible to calculate what the original content has been. It can be used as a fingerprint or as signature. A strong hashing algorithm is resistant to collisions. where other data does not produce the same hash. CRC error correction works in the same way. CRC is not a security hash. By inserting random data, the result can be manipulated to be in the same hash, so it’s easy to find a collision. MD5 and SHA-1 are hashing algorithms that have known collision attacks. Over time, researches will discover more flaws and computing power will increase. MD5 and SHA-1 should be replaced by SHA-2 (SHA256, SHA324 or SHA512) or SHA-3. For passwords, it’s not enough to do hashing only. Dictionary tables with millions of hashes exist that map hashes into simple or often used passwords, so it’s quick to lookup a hash and find it’s matching password. By adding a random string (salt) before hashing, the hashed password will be truly unique. A certificate is a public key, where the owner has a matching private key to prove the certificate is his. Real certificates are signed by a ROOT CA. Certificates only signed with MD5 or SHA1 are weak because, given enough computing power collisions can be created, so that a fake certificate has the same hash. Certificate Signing should use SHA-2 or SHA-3. HMAC is a hash to be used as message authentication code. Poly1305 key broken down in 16 chunks[?]. Poly1305 is a cryptographic message authentication code (MAC) RFC 7539
Asymmetric Ciphers
http://www.crypto-it.net/eng/theory/index.html
Public+Private key pair. Use the private key to sign, so that the recipient can use the public key to prove the sender has the private key. For encryption the sender uses the public key of the recipient, so that only the recipient with the private key can decrypt the message.
https://www.ibm.com/think/topics/cryptography-history
1975: IBM developed the Data Encryption Standard (DES). DES was strong enough to stymie even the strongest computers of the 1970s, its short key length makes it insecure for modern applications
1976: Researchers Whitfield Hellman and Martin Diffie introduced the Diffie-Hellman key exchange method for securely sharing cryptographic keys. This enabled a new form of encryption called asymmetric key algorithms.
1977: Ron Rivest, Adi Shamir and Leonard Adleman introduce the RSA public key cryptosystem. RSA public keys are created by multiplying large prime numbers, which are prohibitively difficult for even the most powerful computers to factor without prior knowledge of the private key used to create the public key.
| Group | Key bit length | Public PEM in bytes |
|---|---|---|
| 1 | 768 | |
| 2 | 1024 | 272 |
| 5 | 1536 | |
| 14 | 2048 | 451 |
| 15 | 3072 | 625 |
| 16 | 4096 | 800 |
| 19 | 256-bit random Elliptic Curve Group | |
| 20 | 384-bit random Elliptic Curve Group | |
| 24 | 2048-bit with 256-bit Prime Order Subgroup |
RSA
RSA stands for Rivest, Shamir and Adleman, who published the PKCS crypto standards in 1977 and formed the RSA company. PKCS#1 is the RSA asymmetric public/private key which relies on the practical difficulty of factoring the product of two large prime numbers. PKCS#1 is now maintained at IETF RFC8017. The RSA Private key components can be packaged using the ASN.1 DER.
RSA Competition (no more prizes after 2007)
https://en.wikipedia.org/wiki/RSA_Factoring_Challenge
https://en.wikipedia.org/wiki/RSA_numbers
RSA-250 decimals / 829bits was factored in February 2020 by Fabrice Boudot, Pierrick Gaudry, Aurore Guillevic, Nadia Heninger, Emmanuel Thomé, and Paul Zimmermann.
RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937
64135289477071580278790190170577389084825014742943447208116859632024532344630238623598752668347708737661925585694639798853367 × 33372027594978156556226010605355114227940760344767554666784520987023841729210037080257448673296881877565718986258036932062711
ASN.1
ITU-T X.693 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.509-201910-I!!PDF-E&type=items
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.693-202102-I!!PDF-E&type=items
ASN.1 is a packing mechanism defining a schema with variable and their types. BER is the binary packing format following a TLV Type Length Value notation. Sequence is 0x30, the length can be multiple bytes where the First bit MSB indicates if more bytes (referred to as octets). The value can be of a type for instance INTEGER, IA5String or UTF8String.
DER Format
RSAPrivateKey ::= SEQUENCE {
version Version,
modulus INTEGER, -- n
publicExponentINTEGER, -- e
privateExponent INTEGER, -- d
prime1INTEGER, -- p
prime2INTEGER, -- q
exponent1 INTEGER, -- d mod (p-1)
exponent2 INTEGER, -- d mod (q-1)
coefficient INTEGER, -- (inverse of q) mod p
otherPrimeInfos OtherPrimeInfos OPTIONAL
}
Letsencrypt has a long explanation on ASN1, explaining why Base64 encoding of a X.509 certificate always starts with MII https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/
ASN1.IO provides a playground and there are some other online decoders
http://www.crypto-it.net/eng/asymmetric/rsa.html
DSA
Digital Signature Algorithm (DSA) is a variant of the Schnorr and ElGamal signature scheme. (NIST) proposed DSA for use in their Digital Signature Standard (DSS) in 1991 ... FIPS 186 in 1994 / FIPS 186-5 from February 2023. (Obsolete)
Curves
Elliptic Curve Digital Signature Algorithm (ECDSA) (SECP Elliptic-curve Diffie–Hellman (ECDH) Ed25519 and Ed448 (EdDSA) X25519 and X448 (ECDH/EdDH)
https://crypto.stackexchange.com/questions/80137/understanding-example-of-ecdsa-p256/80139#80139
ECDSA is specified in SEC1. It's instantiation with curve P-256 is specified in FIPS 186-4 (or equivalently in SEC2 under the name secp256r1), and tells that it must use the SHA-256 hash defined by FIPS 180-4.
openssl ecparam -list_curves openssl ecparam -name prime256v1 -genkey -noout -out prime256v1.pem openssl ec -in prime256v1.pem -pubout -out prime256v1.pub openssl ec -pubin -inform PEM -in prime256v1.pub -outform DER -out prime256v1.der openssl ecparam -name secp256k1 -genkey -noout -out secp256k1.pem openssl ec -in secp256k1.pem -pubout -out secp256k1.pub openssl ec -pubin -inform PEM -in secp256k1.pub -outform DER -out secp256k1.der
https://neuromancer.sk/std/nist/P-256
https://neuromancer.sk/std/network
Cipher Suites
Cipher Suites are combination of algorithms. Both Client and Server negotiate in the handshake what they support. Possible cipher suites are published by IANA http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
For example, the TLSv1.2 mandatory cipher suite (RFC 5246 section-9) from August 2008, TLS_RSA_WITH_AES_128_CBC_SHA can be broken down into RSA the RSA key exchange and authentication AES-128 the AES block cipher with 128 bit keys CBC cipher block chaining is the cipher mode
SHA-1 the message authentication
TLSv1.3 (draft-ietf-tls-tls13 section-9.1) from March 2018 must support at minimum
TLS13_AES_128_GCM_SHA256 and should support
TLS13_AES_256_GCM_SHA384
TLS13_CHACHA20_POLY1305_SHA256
Security protocols and algorithms depend on computational limitations (factoring of large numbers). What was considered secure 10 years ago, has weakened because computing power has increased, and researchers find (partial) methods, reducing the computing power needed to break the algorithm. Algorithms and their application are under constant evaluation and their weaknesses are theoretically, partially and fully broken and the attacks or optimized. Security researchers will publish these attacks. Criminals and state sponsored attackers don’t. Algorithms are reused in different applications. SHA-1 for instance as a signature fingerprint is vulnerable to collisions. It’s possible to change signed certificates that has the same fingerprint. Governmental recommendations on algorithms, key sizes and parameters are EU Enisa, Germany BSI-TR-02102-2, US NIST.SP.800-78-4
https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf
Key Exchange
Asymmetric ciphers are compute intensive and used for exchanging symmetric keys. Avoid using anonymous DH and Export Grade. For DHE and RSA use at least 2048 bit keys or use the new ECDHE.
[IV] Random
[DHE]
RSA and DSA calculate the public/private key once and reuses them between connections. Once this RSA key would be found, previously recorded encrypted messages can be decrypted. For forward secrecy, ECDHE calculates new key pairs for each connection.
NIST (USA) and ECRYPT (EU) publishes comprehensive lists on minimum key size requirements for general purposes. They agree on a near term minimum requirement of 128-bit security.
A good overview of different recommendations is given by https://www.keylength.com/en/compare/
Government usage often requires a higher security level (192–256) and sometimes the use of specific algorithms.
The NIST minimum requirements on security levels shall always be met. 128-bit security should be used, but 112-bit algorithms such as RSA-2048 are acceptable short-term. Algorithms offering less that 112-bit security shall not be supported. If implemented, such algorithms should be disabled by default and only enabled for legacy interop reasons. Such implementations (e.g. supporting SHA-1 certificates or RSA-1024) does not offer acceptable security.
https://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html
Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSAUS -
NIST SP 800-57 Recommendation for Key Management
| Date | Minimum Strength RSA | Discrete Logarithm | Elliptic Curve |
|---|---|---|---|
| < 2030 | 112 | 2048 | 224 |
| ≥ 2030 | 128 | 3072 | 256 |
| ≫ 2030 | 192 | 7680 | 384 |
| ⋙ 2030 | 256 | 15360 | 512 |
EU - ECRYPT CSA Algorithms, key size and protocols report
| Parameter | Near Term | Long Term | ||
|---|---|---|---|---|
| Symmetric Key Size | k | 128 | 256 | |
| Hash Output Size | m | 256 | 512 | |
| MAC Output Size | m | 128 | 256 | |
| RSA Problem | ℓ(n) | 3072 | 15360 | |
| Finite Field DLP | ℓ(pⁿ) | ℓ(p), ℓ(q) | 3072 | |
| ECDLP | ℓ(q) | 256 | 512 | |
| Pairing | ℓ(pᵏⁿ) | ℓ(p), ℓ(q) | 6144 | |
US CNSA 1.0
| Specification | Algorithm | Parameters |
|---|---|---|
| FIPS PUB 197 | Advanced Encryption Standard (AES) | 256 |
| NIST SP 800-56A | Elliptic Curve Diffie-Hellman (ECDH) Key Exchange | Curve P-384 |
| FIPS PUB 186-4 | Elliptic Curve Digital Signature Algorithm (ECDSA) | Curve P-384 |
| FIPS PUB 180-4 | Secure Hash Algorithm (SHA) | SHA-384 |
| IETF RFC 3526 | Diffie-Hellman (DH) Key Exchange | 3072-bit modulus |
| FIPS SP 800-56B | [Rivest-Shamir-Adleman] RSA | 3072-bit modulus |
| FIPS PUB 186-4 | [Rivest-Shamir-Adleman] RSA | 3072-bit modulus |
US -
Algorithm Parameters
Encryption AES-GCM AES-256
Key Exchange Elliptic Curve DH
Finite Field DH P-384
≥ 3072
Digital Signature ECDSA
RSA P-384
≥ 3072
Hash SHA2 SHA-384
For new deployments, Elliptic Curve Cryptography is recommended instead of RSA and finite field Diffie-Hellman.
Function Algorithm NIST
(SECRET) CNSA
(TOP SECRET)
Encryption AEAD AES-128-GCM
AES-128-CCM AES-256-GCM
Key Exchange ECDH
DH Curve P-256
2048 MODP Curve P-384
3072 MODP
Digital Signature ECDSA
RSA Curve P-256
RSA-2048 Curve P-384
RSA-3072
Hashing SHA SHA-256
SHA3-256
SHAKE128 SHA-384
MAC HMAC
KMAC
CMAC
GMAC SHA-256
KMAC128
AES-128
AES-128 SHA-384
Post Quantum Crypto
ISO/IEC/18033-2
NIST SP 800-56A, NISTSP800-56B cryptographic key-establishment
NIST SP 800-208 Leighton-Micali Signature (LMS) , stateful hash-based signatures
FIPS186 and digital signatures
CNSA 2.0 Commercial National Security Algorithm Suite
| ML-KEM | Kyber | ||
| ML-DSA | Dilithium | ||
| SLH-DSA | SPHINCS+ |
Ed25519 uses 32-byte public keys and 64-byte signatures, while ML-DSA (ML-DSA-65) requires 1,952 bytes for the public key and 3,309 bytes for a signature.
IETF Cryptographic Algorithms
IETF/IRTF Crypto Forum Research Group (CFRG) is complementing NIST as global crypto SDO. ChaCha20-Poly1305 is an excellent complement to AES. Curve25519, Curve448, Ed25519, and Ed448 are significantly faster (and more secure) than the NIST curves and ECDSA. XMSS and LMS are stateful quantum-resistant hash-based signature algorithms.
IETF standards use NIST specified hash algorithms (SHA2 and SHA3). New IETF protocols such as TLS 1.3 mandates implementation of P-256 due to its widespread deployment. NIST is planning to approve use of the IETF key exchange and digital signature algorithms.
IETF RFC 8017 is the best reference for PKCS #1 v2.2. Function Algorithm Parameters
Function Algorithm Parameters
(SECRET) Parameters
(TOP SECRET)
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305
Key Exchange ECDH
DH Curve25519 Curve448
Digital Signature EdDSA
XMSS
LMS Ed25519
LMS Ed448
LMS Key Derivation HKDF SHA-256
SHA3-256 SHA-384
NIST
NIST FIPS 197 – Advanced Encryption Standard (AES)
NIST SP 800-38D – Galois/Counter Mode (GCM) and GMAC
NIST SP 800-38C – The CCM Mode for Authentication and Confidentiality
NIST SP 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
NIST FIPS 186-4 – Digital Signature Standard (DSS)
NIST FIPS 180-4 – Secure Hash Standard (SHS)
NIST FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)
NIST FIPS 202 – SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
NISP SP 800-185 - SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash
Commercial National Security Algorithm (CNSA) Suite
IETF RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2
IETF RFC 7539 – ChaCha20 and Poly1305 for IETF Protocols
IETF RFC 7748 – Elliptic Curves for Security
IETF RFC 8032 – Edwards-Curve Digital Signature Algorithm (EdDSA)
IETF RFC 8391 - XMSS: eXtended Merkle Signature Scheme
IETF RFC 8554 - Leighton-Micali Hash-Based Signatures
IETF RFC 5869 - HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
Deprecated Legacy Algorithms
Scheme Strength Direction
RC4, MD2, MD5, SHA-1 Broken Shall be forbidden
< 2048-bit RSA, MODP < 112 Shall be forbidden
< 255 bit ECC < 128 Shall be forbidden
3DES, Blowfish, etc.
(All block ciphers with less than 128-bit block length) < 112 Shall be forbidden
SSLv3, TLS 1.0, TLS 1.1, DTLS 1.0 Broken Shall be forbidden HMAC-MD5 Broken Shall be forbidden CBC-mode Broken Shall be phased out IND-CPA encryption (encryption without integrity) Broken Shall be phased out
Key exchange without PFS Broken Shall be phased out
RSAES-PKCS1-v1_5, RSASSA-PKCS-v1_5 Broken Shall be phased out
SHA-224, SHA3-224 112 Shall be phased out HMAC-SHA1, SHA-1 PRF 128 Shall be phased out ECRYPT CSA Algorithms, key size and protocols report 2018
BSI TR-02102-1 - Cryptographic Mechanisms: Recommendations and Key Lengths
ECC has significantly smaller key sizes than RSA (256 bits compared to 3072 bits), significantly smaller signatures (64 bytes compared to 384 bytes), and significantly faster key generation. At the 128-bit security level, ECDSA with the P-256 curve has significantly better performance than RSA in use cases where both signing and verification is needed. The new ECC algorithms Curve25519 and EdDSA standardized by CFRG significantly improve the performance of ECC, while at the same time improving security. ECDSA with P-256 or P-384 should be the first choice of signature algorithm for most applications. • For signature algorithms, a good choice is to use ECDSA or EdDSA with a strong curve. See recommended algorithms for more information. • For key exchange, a good choice is to use ECDH with a strong curve. Ephemeral ECDH offers perfect forward secrecy. • For public key encryption, a good choice is to use ECIES with a strong curve and a strong selection of symmetric algorithms. • The new ECC algorithms Curve25519 and EdDSA standardized by CFRG significantly improve the performance of ECC, while at the same time improving security.
Best practice to accomplish encryption is to use an AEAD algorithm. AES-GCM is a good choice for a system where processor instructions for that algorithm are available. ChaCha20-Poly1305 is a good alternative for e.g. pure software implementations. • If using multiple symmetric algorithms, best practice is to use separate keys for each algorithm. Cryptographic protocols typically achieve this by deriving multiple keys from a master secret through a key derivation function. • If only data integrity and authentication is required, then HMAC with a strong hash function is a good choice. See recommended algorithms for strong hash functions. A Key Derivation Function (KDF) is typically used to derive multiple keys from an initial master secret. See “Symmetric algorithms” for why multiple keys may be required. Key derivation may also be used to “erase” mathematical structure if the master secret is e.g. the shared secret from an asymmetric key exchange algorithm. • Best practice is to use a collision resistant cryptographic hash function whenever a cryptographic hash function is needed. See recommended algorithms for such strong hash functions. • A good choice for a key derivation function is HKDF with a strong hash function. • If configuring a key derivation function by hand for custom usage, then best practice is to use known auxiliary information as additional input. Adding party IDs, protocol version, symmetric algorithm identifiers or similar context to key derivation may e.g. increase misuse resistance or provide defense in depth. However, note that the kind of configuration described above is an advanced procedure that must be done with care to not harm security. Only SSH-2 shall be supported. SSH-1 shall be disabled.
Recommended Algorithms
Key Exchange (KEX) curve25519-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
Encryption (Cipher) aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
Hostkey format ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
User Authentication publickey + MFA
Common SSH implementations are OpenSSH and libssh. Using the latest version of OpenSSH is recommended. It is recommended to configure SSH according to the Mozilla Modern configuration. Software versions no longer receiving security patches shall not be used. Other relevant source of information are
Other relevant source of information are BSI TR-02102-4 and NIST IR 7966. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-4.pdf?__blob=publicationFile
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
Mozilla OpenSSH Guidelines
https://infosec.mozilla.org/guidelines/openssh.html
BSI TR-02102-4 - Cryptographic Mechanisms: Recommendations and Key Lengths Part 4 – Use of Secure Shell (SSH)
NIST IR 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH)
OpenSSH
For TLS see also BSI TR-02102-2: Use of Transport Layer security:
Only IKEv2 and ESP is recommended.
IKEv2 Recommended Algorithms
Encryption ENCR_AES_GCM_16
ENCR_CHACHA20_POLY1305
Pseudorandom Function PRF_HMAC_SHA2_256
PRF_HMAC_SHA2_384
PRF_HMAC_SHA2_512
Diffie-Hellman Group Curve25519 (group 31)
256-bit random ECP group (group 19)
384-bit random ECP group (group 20)
Authentication method Digital Signature (method 14) with ECDSA or RSASSA-PSS
ESP Recommended Algorithms
Encryption ENCR_AES_GCM_16
ENCR_CHACHA20_POLY1305
Authentication AUTH_HMAC_SHA2_256_128
AUTH_AES_128_GMAC AUTH_AES_256_GMAC
3GPP profiles for IKEv2 and ESP algorithms are specified in TS 33.210 and TS 33.310. IETF profiles are specified in RFC 8221 and RFC 8247.
Other relevant source of information NIST 800-77 Rev. 1 (Draft), BSI TR-02102-3 and ANSSI DAT-NT-003-EN.
The Core Infrastructure Initiative (CII) (by the Linux Foundation) organizes "The Best Practices Badge" program, which is an open source secure development maturity model.
More information and the complete list of the criteria can be found in the Badge Program github repository.
https://www.coreinfrastructure.org/
https://www.coreinfrastructure.org/programs/badge-program
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
HSM
HSM or other Secure elements offer an PKCS#11 Cryptographic Token Interface, describing an interface to load keys into a slot and performing cryptographic operations, so that the keys would not have to leave the system. Documentation for PKCS#11 was adopted by oasis-open.org
OpenSC is the SoftHSM, their pkcs11-tool can be used
http://wiki.ncryptoki.com/MainPage.ashx
apt install softhsm2 opensc softhsm2-util --init-token --slot 0 --label "softhsm" ls -la /var/lib/softhsm/tokens/ export p11pin="1234abcd" export keyid=$(uuidgen | tr -d -)
For OP-TEE the same commands can be used, but with a different module
alias pkcs11-tool='/usr/bin/pkcs11-tool --module /usr/lib/libckteec.so.0'
alias pkcs11-tool='/usr/bin/pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so'
pkcs11-tool --slot-index 0 --init-token --label softhsm --so-pin ${p11pin}
pkcs11-tool --login --pin ${p11pin} --init-pin --so-pin ${p11pin}
pkcs11-tool --show-info
pkcs11-tool --list-mechanisms
pkcs11-tool --list-objects
pkcs11-tool --list-slots
creating a key pair
pkcs11-tool -l -p ${p11pin} -k --id ${keyid} --label "key-1" --key-type rsa:4096
pkcs11-tool -l -p ${p11pin} --list-objects
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type pubkey -o key-1.der
openssl rsa -pubin -inform DER -in key-1.der -outform PEM -out key-1.pem
importing a private key
openssl genrsa -out csf0.key 2048
softhsm2-util --import csf0.key --token "softhsm" --label "csf0" --id ${keyid} --pin ${p11pin}
pkcs11-tool -l --pin ${p11pin} --write-object ./csf0.key --type privkey --id ${keyid}
importing the public key
openssl rsa -in csf0.key -pubout -out csf0.pem
pkcs11-tool -l --pin ${p11pin} --write-object ./csf0.pem --type pubkey --id ${keyid}
exporting public key
pkcs11-tool -l -p ${p11pin} --list-objects
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type pubkey -o csf0.der
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type privkey -o private_key.pem
OpenSSL
https://wiki.openssl.org/index.php/OpenSSL_3.0
openssl genrsa -out private-key.pem 4096 openssl rsa -in private-key.pem -text -noout openssl asn1parse -in private-key.pem openssl rsa -in private-key.pem -pubout -out public-key.pem openssl asn1parse -in public-key.pem openssl rsa -pubin -inform pem -in public-key.pem -outform der -out public-key.der
openssl dgst -sha256 -hex ranger_1.8.1-0.2_all.deb openssl dgst -sha256 -sign private-key.pem -out testsign.sha256 ranger_1.8.1-0.2_all.deb openssl base64 -in testsign.sha256 -out signature openssl base64 -d -in signature -out testsign.sha256 openssl dgst -sha256 -verify public-key.pem -signature testsign.sha256 ranger_1.8.1-0.2_all.deb
openssl pkeyutl -sign -inkey private-key.pem -in file -out sig openssl pkeyutl -sign -in file -inkey private-key.pem -out sig -pkeyopt md:sha256 openssl pkeyutl -verifyrecover -in sig -inkey private-key.pem openssl pkeyutl -verify -in file -sigfile sig -inkey private-key.pem
openssl req -subj '/CN=www.mozilla.org/O=Mozilla/OU=WebSecurity/L=locality /ST=state/C=FI/emailAddress=jan@janmg.com/' -key public-key.pem -out host.csr openssl ca -cert ca.crt -keyfile ca.key -in host.csr -out public.crt
openssl x509 -noout -modulus -in public.crt | openssl sha256 openssl rsa -noout -modulus -in private-key.pem | openssl sha256 cat public-key.pem | base64 -d | openssl asn1parse -inform DER -i -strparse 19
https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm
TLS Transport Layer Security
TLS Origins
ITU-T and ISO defined networking protocols in the ‘80s and ‘90s. Today the visible remains are the OSI model, the IS-IS protocol used between IP routers, SNMP, LDAP and the PKIX infrastructure with the X.509 certificates adopted by IETF as RFC 5280. Certificates were standardized as part of the OSI protocols, which where directly competing with IETF TCP/IP during the protocol wars.
Certificates were invented as part of the X.500 "Directory", which would have been an "internet" with "directory information" structured like the yellow pages. The full history is described as "weird and wonderful" http://sec.cs.kent.ac.uk/x500book/.
LDAP is the spinoff based on IP, where LDAP describes a tree-like interface into a backend database. LDAP is mostly used for authentication. Lightweight is a misnomer, the internals are described in the book "LDAP for rocket scientists" https://www.zytrax.com/books/ldap/
Netscape SSLv3 from 1996 was the first usable encryption standard for the web. IETF took over the development and renamed SSL to TLS. The internal version number for TLSv1.3 is 0x0304, which is a continuation of the SSL numbering. TLS certificates incorporate the public key, a serial, criteria for validity, a url for certificate revocation, a subject (optionally also SAN), an issuer who signed the certificate. The certificate can therefor be trusted if the issuer certificate is included in the truststore.
SSL vs TLS
SSL secure socket layer and its successor TLS transport layer security are protocol on top of TCP to sign and encrypt traffic. The UDP equivalent is DTLS. HTTPS is HTTP on top of TLS on TCP/443. Some protocols support StartSSL to start the handshake without encryption and if both client and server agree will switch to using TLS.
SSL was standardized by Netscape based on ITU-T X.500 and RSA PKCS standards. TLS is the successor specified under IETF.
All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
| Version | By | Date | Security | |
|---|---|---|---|---|
| SSLv1 | Netscape | 1994 | Never released | |
| SSLv2 | Netscape | 1995 | Vulnerable | |
| SSLv3 | Netscape | 1996 | Vulnerable | |
| TLSv1.0 | [rfc:2246 IETF RFC 2246] | 1999 | Header Compression is broken | may be needed for older clients like Java 6, Windows 7/Server 2008, IE 8 or Android 4 |
| TLSv1.1 | [rfc:4346 IETF RFC 4346] | 2006 | Quickly replaced by TLSv1.2 | |
| TLSv1.2 | [rfc:5246 IETF RFC 5246] | 2008 | Good enough | |
| TLSv1.3 | IETF RFC8446 | 2018 | Introduces features like 0-RTT, removes legacy ciphers |
https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols
https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
TLS protocol
TLS messages are encapsulated in a record layer. The handshake starts with a client_hello where the client expresses which versions of TLS can use and which ciphersuites it can use and a random seed. The server responds with a server_hello with it’s certificate, the ciphersuite it picked and it’s random. Then the client sends a master secret encrypted with the servers public key, so that the server can decrypt the master key. The most important values negotiated are • TLS version to use • Verify hashing of public/private key (X.509 certificate) • Asymmetric key • Exchange symmetric session keys • Negotiate stream/block cipher to encrypt the payload. • Choose random Initialization Vector TLS used by default MAC-then-encrypt. The message padding can lead to attacks, which can be mitigated by authenticated encryption like AES-GCM. Cryptography suites involve multiple steps and for each step different algorithms can be chosen. For instance, RSA describes multiple standards (PKCS). PKCS#1 describes both public/private asymmetrical keys and encoding/padding schemes for encryption/decryption and verifying of signatures. It’s possible to use RSA for some steps and other algorithms for the other steps.
In a TLS message there are 3 places where a version is set. For backwards compatibility In the record layer the minimum version is set (here 0x0301 for TLS 1.0). In the ClientHello the version 0x0304 for TLS 1.2 originally was the highest supported version. 1.2 supports extensions. Since TLS 1.3 the extension “supported version” contains a list of versions that are supported.
TLS Certificate Profiles
Netscape developed SSL by adopting X.500. In 1999 when IETF continued the protocal as TLS it has created profiles to use X.509 certificates for instance for Webservers and Email.
| Version | Specification | Date | Security |
|---|---|---|---|
| X.509v1 | T-REC-X.509/en | July 1988 | |
| X.509v2 | 1993 | ||
| X.509v3 | June 1996 | Additional extension fields | |
| IETF PKI | RFC2459 | January 1999 | Profiles for applicability |
| IETF PKI | RFC3280 | April 2002 | |
| IETF PKI | RFC5280 | May 2008 |
TLS certificate format is based on ITU-T X.509v3. It uses ITU-T ASN.1 for byte-packing structures in a TLV Type-Length-Value format DER. To transfer bytes, private keys and certificates can also be encoded as PEM which is the Base64 representation, wrapped with a start and end line.
X.509v3 certificates contain the public parameters that define the validity of the certificate. The certificate should have a matching private key that must be kept safe. Important parameters are the validity period, the subject and the issuer who signed the certificate and the signature of the private key. In v3 extension attributes were introduces, key usage and subject alt name A certificate’s subject can be a URL for HTTPS or an email address for signing or encrypting emails. Certificates where the subject and the issuer are the same are self signed. A certificate is usually signed by one or more intermediate certificates that are themselves signed by a ROOT CA’s. A client has a trust store of the ROOT CA's and everything signed by that tree is considered trusted. Trusted ROOT CA’s are member of the CA/Browser Forum. Operating Systems and/or Browsers maintain a list of these ROOT CA's in a truststore. ROOT CA’s that violate rules are removed.
Software that use certificates must be configured with either the certificate, intermediate-certificates and private key as individual files, or as combination of intermediate-certificate and certificate and sometimes also including the private key. The terminology can vary between implementations, so don't expect consistency. For instance intermediate certificate can be confusingly referred to as 'ca certificate'.
There are several file formats for encoding certificates. The binary format can be one of the PKCS based p7b, p12 or pxf (RFC 7292) or in the ASN.1 DER format. DER can be encapsulated in Base64 as PEM (Privacy Enhanced Mail RFC 7468) and put between begin and end labels
-----BEGIN <LABEL>----- <base64> -----END <LABEL>-----
-----BEGIN CERTIFICATE----- MII…== -----END CERTIFICATE-----
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t
Certificates and private keys always start with MII, because inside the BASE64 the certificate is binary encoded according to ASN.1 which is a TLV (type-length-value) binary encoding. The packing structure is defined in X.509
TLS Termination
A TLS connection can be terminated on an edge server like HAPROXY, Apache HTTP or NGINX or a hardware loadbalancer like BIG IP F5. These servers can forward the traffic either unencrypted to a backend, or passthrough the TLS traffic unmodified or be re-encrypted. The NodeJS implementation for HTTP2 requires that the server is terminated on the server, so it needs one of the last two options.
A TLS Certificate is the public key for which the owner can prove he has the matching private key. A certificate has a subject for which it is valid (for instance a domain name). And an issuer who signed the certificate. If the certificate is signed by a RootCA, the client can verify the certificate chain. 5.2 X.509 Certificates X.509 was created by ITU-T as part of X.500 (DAP) recommendations. This legacy is still visible in the Common Name structure, as still used in LDAP and certificates can use ASN.1 (Type Length Value) as file format. Another legacy is the use of the OID tree, where .1.3.6.1.5.5.7.3.9 means iso.identified-organization.dod.internet.security.mechanisms.pkix.keyPurpose.ocspSigning
TLS uses X.509 certificates. the subject and keyUsage. Certificates have a typical lifetime of maximum 3 years. Intermediate certificates may have a 10 years expiry and root certificates are often valid for multiple decades.
A certificate is a public key, where the owner has a matching private key. A certificate can be used to prove that a servers ownership. If the certificate is signed by a trusted authority, the client can verify the validity. For instance a bank can create a certificate to prove that the URL to your website is really from that bank and a browser can trust this certificate if it has been signed by a ROOT CA it trusts.
Root CA are embedded in browsers and operating systems in a trust store. Root CA’s use intermediate certificates for signing requests.
https://tls-observatory.services.mozilla.com/static/certsplainer.html
https://gchq.github.io/CyberChef/
openssl genpkey openssl genrsa -aes128 -out fd.key 2048 openssl rsa -text -in fd.key
modulus publicExponent (65537) privateExponent prime1 prime2 exponent1 exponent2 coefficient
Private keys are generated using system entropy. On virtual machines creating enough ‘events’ will create enough randomness. rng-tools or virtio-rng can create entropy. cat /proc/sys/kernel/random/entropy_avail
TLS Handshake
After the initial TCP handshake (3 way SYN - SYN/ACK – ACK). TLS uses a 4-way handshake (ClientHello - ServerHello - ServerKey – ClientKey).
Before the TLS version is negotiated the initial version in the ClientHello record is set to 1.0. The ClientHello itself states the maximum TLS version it can use.
TLS 1.3 can use 0-RTT to reduce the roundtrips and the version is negotiated as a list.
https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL#The_SSL_Handshake
+ Indicates noteworthy extensions sent in the previously noted message.
- Indicates optional or situation-dependent messages/extensions that are not always sent.
{} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys derived from traffic_secret_N
https://blog.cloudflare.com/introducing-tls-1-3/
TCP Fast Open, TLS False Start
HTTPS
HTTP is a text based protocol over TCP. HTTPS is an HTTP connection wrapped in a TLS connection over TCP. HTTPS is a different scheme. IANA has assigned TCP/80 to HTTP servers and TCP/443 to HTTPS servers (by default). Similarly, LDAP is assigned default TCP/389 and LDAPS is TCP/636. In Linux these default port assignments can be found in /etc/services.
The alternative to different assigned port numbers dedicated for TLS is to use StartSSL to upgrade a regular TCP to TLS. HTTP does not support StartSSL, instead an HTTP 301 redirect is used to redirect to the HTTPS location.
HTTPS on TCP/443 is using the HTTP protocol wrapped around TLS. Often only the server offers a certificate to authenticate itself to the client. But with a personal client certificate installed in the client, mutual authentication can be done.
A full URL should contain the schema defines if TLS should be negotiated first.
schema://domainname:[port]/
Tunnel Socks over TLS
https://wiki.archlinux.org/title/HTTP_tunneling#Using_corscrew_and_HTTP_CONNECT
ROOT CA
Root program, truststore
Namecheap
Namecheap offers certificates through CA’s like Symantec Verisign, Geotrust and Comodo.
For less than $30 an Comodo PositiveSSL can be obtained for domain validation. The CA validates that you control the domain, by either sending an email to an address listed in the whois information, by DNS requesting a domain where the CNAME is a hash. Or by downloading a file from the webserver with that domain.
The IP address from Comodo is in the range of 91.199.212.0/24.
Letsencrypt
letsencrypt.org from ISRG offers free certificates with a short validity period. Certificates are signed by Identrust X3, so they can be verified by clients. Letsencrypt uses the ACME API for certificate ordering and renewal. The tool certbot uses this API.
certbot certonly --standalone --email ${MAIL} --agree-tos -d ${DOMAIN}
cd /etc/letsencrypt/live/
cat privkey.pem fullchain.pem > combined.pem
X3 Root
https://www.identrust.com/support/downloads
Convert from DER to PEM and then from P7B to Cert
openssl x509 -inform der -in trustidrootx3_chain.p7b -out root.p7b
openssl pkcs7 -print_certs -in root.p7b -out root.pem
https://letsencrypt.org/certificates/
docker volume create letsencrypt
docker run -p 80:80 -v letsencrypt:/etc/letsencrypt/ certbot/certbot certonly -m --register-unsafely-without-email --agree-tos --standalone --non-interactive -d server.northeurope.cloudapp.azure.com
docker run -ti -v letsencrypt:/etc/letsencrypt/ certbot/certbot /bin/sh
openssl dhparam -out dhparam.pem 4096
docker run -d -p 80:80 -p 443:443 -v /home/etmjang/nginx.conf:/etc/nginx/conf.d/default.conf -v /home/etmjang/dhparam.pem:/etc/nginx/dhparam.pem -v letsencrypt:/etc/letsencrypt/ --name nginx nginx
docker logs nginx docker exec -ti nginx /bin/bash
SSL as configuration statement deprecated in older version of NGINX. This should be now a separate server
server {
location /.well-known {
alias /var/www/html/.well-known;
}
}
server {
listen [::]:443 ssl http2 default_server ipv6only=off;
server_name server.northeurope.cloudapp.azure.com;
ssl_certificate /etc/letsencrypt/live/server.northeurope.cloudapp.azure.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/server.northeurope.cloudapp.azure.com/privkey.pem; # managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/server.northeurope.cloudapp.azure.com/fullchain.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-XTS-SHA384:ECDHE-RSA-AES256-XTS-SHA384:ECDHE-ECDSA-AES128-CTR-SHA256:ECDHE-RSA-AES128-CTR-SHA256';
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;
ssl_dhparam /etc/nginx/dhparam.pem;
The TLS connections can be terminated on a service that serves as a frontend to an unprotected server. Some applications do not provide TLS natively, are complex to setup or have a negative performance impact. For instance, Apache Tomcat can be configured to terminate TLS on port 8443, but to run as unprivileged user on unix privileged ports (under 1024) unless tricks are done with authbind, JSVC, iptables redirect or setcap http://www.klawitter.de/tomcat80.html
Apache HTTPD starts one control thread as root which starts listening to port TCP/80 or TCP/443 and spawns sub-processes under an unprivileged user. For performance reasons it’s possible to terminate TLS connections in a loadbalancer like Cisco ACE 30 or BIGIP F5.
self signed certificate
This creates a serial file, generates a PEM RSA private key and then creates a ca certificate. The private key is protected with a passphrase.
echo 00 > ca.srl
openssl genrsa -aes256 -out ca.key 4096
openssl req -subj '/CN=JANMG_ROOT_CA' -new -x509 -days 3652 -key ca.key -out ca.crt
This creates a private key, a signing request for the key and a certificate is created with the details in the signing request and signed with the ca certificate.
openssl genrsa -aes256 -out host.key 2048
openssl req -subj '/CN=hostname' -new -key host.key -out host.csr
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -CAkey ca.key -out host.crt
The private key is protected with a passphrase, but when starting up a webserver the passphrase needs to be entered. This command removes the passphrase from the private key
openssl rsa -in host.key -out host.key
This prints the certificate as text
openssl x509 -in ca.crt -noout -text
This copies the files to the right directories for Redhat
cp *.crt /etc/pki/tls/certs/
cp *.key /etc/pki/tls/private/
This copies the private keys and the public certificates to the correct locations.
To trust the selfsigned certificate add the certificate into the ca-certificates directory /usr/local/share/ca-certificates/ and run update-ca-certificates. This will rebuild the /etc/ssl/certs/ca-certificates.crt file with all trusted certificates. (In RedHat /etc/tls/certs/) ca.srl is stepped and used as serial number for the certificate that is signed, unless -set_serial is used.
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -set_serial "0x$(openssl rand -hex 16)" -CAkey ca.key -out host.crt
Local Certificates
Browsers follow CA/Browser and therefor local webservers can not have certificates relevant in the local scope.
For instance the Philips HUE has an mdns / dns-sd discovery address https://philips-hue.local but the certificate is self signed, which browsers don't accept by default. No global CA is allowed to sign this under the rules of the CA/Browser Forum.
https://cabforum.org/uploads/CA-Browser-Forum-BR-v2.0.1.pdf
7.1.2.7.12 Subscriber Certificate Subject Alternative Name
https://iotsecurityfoundation.org/router-and-iot-device-vulnerabilities-solutions-to-a-design-flaw/
https://specs.manysecured.net/suib/
- Address of the local device
- Browser
- Certificate trust
MDNS
mdns-scan
Resolve-DnsName philips-hue.local dig -p 5353 philips-hue.local @224.0.0.251
https://www.gabriel.urdhr.fr/2019/04/02/llmnr-mdns-cli-lookup/
apk add avahi service avahi-daemon start avahi-browse -a
Docker
Docker registries by default have to be HTTPS. The alternative is to mark the registry in all the clients as INSECURE or to use selfsigned certificates and add the certificates
-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/ssl/certs/docker-registry -e REGISTRY_HTTP_TLS_KEY=/etc/ssl/private/docker-registry
/etc/sysconfig/docker
--insecure-registry myregistrydomain.com:5000
boot2docker echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile
Other encrypting protocols
SSH
SSH has defined it’s own protocols similar to TLS. It’s using the same components and negotiations like Keyexchange, Encryption and IV. Since 2006 the version of the SSH Protocol should be SSHv2 only. SSH is most frequently used for remote terminal (secure shell) but it’s subsystem can also be used for SFTP for file transfers over the SSH channel.
Putty format, OpenSSH format
IPsec
IPsec originates as header for IPv6 and has been ported as protocol on IPv4.
RFC 4301
The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of the sequence of letters "IPsec" should be understood to refer to the IPsec protocols.
IPsec has an AH header for signing the IP packets with hashes, so that the protocols are in clear text, but the receiver can verify the traffic comes from the sender. IPsec has an ESP header that provides encryption. IPsec can be used in transport mode between two end-points or in tunnel mode to route traffic from one network to another network over a secure route.
IPsec can be used in transport mode between two end-points as client to server mode or in tunnel mode to route traffic from one network to another network over a secure route. In that case both sides can be an initiator that starts the connection(s)
Phase I, Negotiate Setting, e.g. with IKE
Phase II, Establish connection.
https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
IKEv1
Initial Key Exchange
RFC 2409 obsoleted by IKEv2
Oakley protocol and ISAKMP.
IKEv2
RFC 7296
IKEv2 adds EAP authentication IKEv2 adds MOBIKE IKEv2 adds NAT traversal IKEv2 adds tunnel alive detection IKE key exchange
SPD Security Policy SAD Security Association.
Certificates
File format
DER is an ASN.1 file format. PEM is a DER in Base 64 with ascii armor
1. DER ASN.1
2. SSLeay format (used by OpenSSL)
3. PKCS#8 / RFC5208
4. PKCS#7 as supported by Java Keytool
5. PKCS#12 PFX or P12, certificate chain, used commonly by Microsoft and as method to import private keys into a Java Keystore
SAN
A certificate can be valid for multiple domains when specified in the subjectAltName. The software must support this extension. It will overrule the subject CN
https://wiki.cacert.org/FAQ/subjectAltName
Certificate Authority
ROOT CA
- Server Cert WG
- Code Signing Cert WG
- S/MIME Cert WG
- Net-Sec WG
Certificate Transparency
https://certificate.transparency.dev/howctworks/
https://datatracker.ietf.org/doc/html/rfc6962
A precertificate contains all the information a certificate does. It also has a poison extension so that user agents won’t accept it. Precertificates help break a deadlock in CT. Before a CA can log a certificate, the certificate needs an SCT (Signed Certificate Timestamp). But for the certificate to get an SCT, it needs to have been submitted to a log.
TPM 2.0
Attestation
IEEE 802.1AR
Secure Device Identity
https://1.ieee802.org/security/802-1ar/
IDevID
BRSKI
Vendor certificates
ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Autonomic Control Plane
https://datatracker.ietf.org/doc/html/rfc8995
Browsers
The CA / Browser forum is a group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS and code signing. The CA’s are the companies that sign certificates after they verified the owner. Browsers and Operating Systems have a root store with default CA certificates to trust. All certificates in the chain that are signed by the CA ROOT are then trusted. You can add or remove certificates.
https://cabforum.org/browser-os-info/
| Owner | Root Store | Link | |
|---|---|---|---|
| Adobe | www.adobe.com/security/approved-trust-list.htm | ||
| Mozilla | Mozilla Root Certificate Program | Overview of All CA-Related Mozilla Documentation | |
| Microsoft | Microsoft Root Certificate Program | aka.ms/RootCert | |
| dev.chromium.org/Home/chromium-security/root-ca-policy | |||
| Apple | www.apple.com/certificateauthority/ca_program.html | ||
| Oracle | www.oracle.com/technetwork/java/javase/javasecarootcertsprogram-1876540.html |
Linux includes the Mozilla NSS services which comes with a Root CA’s usually installed in /etc/ssl
The Chrome Browser uses the platform specific truststore. ChromeOS uses it’s own Chromium Root CA.
Internet Explorer uses the windows certificate trust store. In the Microsoft Management Console (MMC) the certificate snap-in can show and manage the windows certificate store.
TLS 1.2 Support
The versions of clients that can initiate TLSv1.2 connections should be at least.
• Android 4.4.2
• Firefox 32
• IE 11
• IE Mobile 11
• Java 8
• Safari 7
TLS 1.3 Support
TLS 1.3 was in state AUTH48*R with the last author review being done before release
https://www.rfc-editor.org/cluster_info.php?cid=C357
https://tools.ietf.org/html/draft-ietf-tls-tls13-28
rfc:8446
Firefox 63 and Chrome 70 in October 2018 will support TLS 1.3 as 0x0304. Older versions support Draft 28 as 0x7F1C.
https://github.com/mozilla/gecko-dev/blob/.../security/nss/lib/ssl/sslproto.h
https://hg.mozilla.org/mozilla-central/
OpenSSL version 1.1.1 from September 2018 supports TLSv1.3
include/openssl/tls1.h
NGINX 1.13.* compiled with --with-openssl-opt=enable-tls1_3 and configured with ssl_protocols TLSv1.3; and ssl_ciphers TLS13-AES-128-GCM-SHA256
Wireshark
https://wiki.wireshark.org/TLS
TLS traffic is encrypted, and the payload data is not readable. Wireshark can fetch the session key data from the browser if the system variable SSLKEYLOGFILE is set. Wireshark can read from this file and decode the trace.
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/
Firefox needs NSS_ALLOW_SSLKEYLOGFILE=1 explicitly set during compilation or use the Firefox Developer edition.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
Windows
Schannel. Windows secure channel is the subsystem that deals with encryption Certmgr is the GUI for managing certificates Certutil is the Commandline tool for managing certificates Disabling TLS 1.0 https://docs.microsoft.com/en-us/security/engineering/solving-tls1-problem (backported to Server 2008 SP2)
.NET Framework versions prior to 4.7
UseStrongCrypto
Linux
Linux kernel supports TPM and SHA/AES
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto
Redhat Enterprise Linux
Redhat is using the NSS utils for certificate management http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
yum install ca-certificates
cd /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
/etc/pki/tls/certs/
certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert
vi /etc/openldap/ldap.conf
TLS_REQCERT never
Alpine Linux
apk add ca-certificates
/usr/local/share/ca-certificates/
update-ca-certificates
/etc/ssl/certs/
/usr/bin/c_rehash /etc/ssl/certs
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
rm -rf /etc/ssl/certs/ca-certificates.crt
update-ca-certificates
cURL
wget
Qt
OpenSSH
Apache Traffic Manager
OpenConnect
TianoCore/EDKII
Implementations
Java Keystore / Truststore
Convert between formats
KEYTOOL
keytool -keystore janmg.jks -list
P7B
keytool -keystore janmg.jks -exportcert -alias janmg1 > janmg.p7b
keytool -printcert -v -file janmg.p7b
keytool -list -v -keystore janmg.jks -alias janmg1
openssl x509 -text -inform DER -in janmg.p7b
PEM
openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt
openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt
openssl x509 -text -inform PEM -in janmg.crt
DER / XER
...
P12
openssl pkcs12 -in janmg.p12 -nodes -legacy
Keystore to P12
keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
openssl pkcs12 -info -in janmg.p12
openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key
VERIFY MATCH
openssl x509 -noout -modulus -in juststar.crt | openssl md5 openssl rsa -noout -modulus -in janmg.key | openssl md5
P12 to Keystore
openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12 keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12
Merge private key and chain
cat privkey.pem fullchain.pem > combined.pem
JRUBY
jruby-openssl https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol
GO crypto/tls
NGINX
HAPROXY
/etc/haproxy/haproxy.cfg
tune.ssl.default-dh-param 2048 ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
ssl-server-verify none ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
frontend http-in
bind :::80 v4v6 tfo
mode http
redirect scheme https code 301 if !{ ssl_fc }
frontend https-in
bind :::443 v4v6 tfo ssl crt /etc/letsencrypt/live/janmg.com/combined.pem alpn http/1.1,http/1.0 http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" http-response set-header X-Content-Type-Options "nosniff" http-response set-header X-Frame-Options "DENY" http-response set-header X-XSS-Protection "1; mode=block" http-response set-header Referrer-Policy "strict-origin" http-response set-header Content-Security-Policy "default-src 'none'; base-uri 'none'; style-src 'self'; script-src 'self'; object-src 'none'; img-src 'self'; media-src 'none'; form-action 'none'; frame-src 'self'; frame-ancestors 'none'; font-src 'self'; connect-src 'self'" default_backend app
backend app
balance source http-request add-header X-Forwarded-Proto https
OPENLDAP
LDAPS
cat root.pem chain.pem > root-intermediate.pem
dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem
dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/cert.pem
dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem
ldapmodify -Y EXTERNAL -H ldapi:/// -f certs.ldif
SSL Libraries
https://www.feistyduck.com/library/openssl%2dcookbook/
1995 SSLeay (by Eric A. Young and Tim J. Hudson) 1998 OpenSSL 2003 GnuTLS 2006 wolfSSL 2014 LibreSSL (OpenBSD fork of OpenSSL) 2014 BoringSSL (fork of OpenSSL by Google) MBEDTLS
NSS
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS
Mozilla maintains the NSS (Network Security Services) project that implements TLS and S/MIME for clients like Firefox.
https://hg.mozilla.org/projects/nss
OpenSSL
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.
https://www.openssl.org/source/
https://endoflife.date/openssl
| version | support | introduced | last version | redhat |
|---|---|---|---|---|
| 0.9.8 | eol | Jul 2005 | 0.9.7m (February 23, 2007) | |
| 1.0.0 | eol | Mar 2010 | 1.0.0t (December 3, 2015) | |
| 1.0.1 | eol | Mar 2012 | 1.0.1u (Sep 22, 2016) | 1.0.1e-51.el7_2 |
| 1.0.2 | eol | Jan 2015 | 1.0.2n (Dec 7, 2017) | |
| 1.1.0 | eol | Aug 2016 | ||
| 1.1.1w | eol | May 2018 | First version to support TLS 1.3 | el8 1.1.1k |
| 3.0 | lts | Sep 2021 | Redesign with providers instead of engines | |
| 3.1 | Mar 2023 | |||
| 3.2 | Nov 2023 | |||
| 3.3 | Apr 2024 |
https://wiki.openssl.org/index.php/TLS1.3
https://www.openssl.org/docs/man3.0/man7/migration_guide.html
https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
wget https://www.openssl.org/source/openssl-3.0.8.tar.gz tar xvzf openssl-3.0.8.tar.gz cd openssl-3.0.8/ perl Configure perl configdata.pm --dump perl Configure no-deprecated no-ssl no-des perl configdata.pm --dump perl ./Configure linux-x86_64 --prefix=/usr --libdir=lib --openssldir=/etc/ssl enable-ktls shared no-zlib no-async no-comp no-idea no-mdc2 no-rc5 no-ec2m no-ssl3 no-seed no-weak-ssl-ciphers enable-ec_nistp_64_gcc_128 -Os -fstack-clash-protection -Wformat -Werror=format-security -fno-plt -g -Wl,--as-needed,-O1,--sort-common -Wl,-z,pack-relative-relocs -Wa,--noexecstack
https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/openssl/openssl-3.1.5-r5.log
Ubuntu
./Configure shared --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/x86_64-linux-gnu no-idea no-mdc2 no-rc5 no-zlib no-ssl3 enable-unit-test no-ssl3-method enable-rfc3779 enable-cms no-capieng no-rdrand enable-ec_nistp_64_gcc_128 make sudo make install
Configuration options don't seem to matter much for OpenSSL 3.0
Redhat picks one version for a main release and will backport all security patches for that version. For RHEL 7 openssl version 1.0.1e has been picked and Redhat has created 51 patches, with backports to the latest 1.0.1t. The benefit to enterprises is that they never have to update their applications and can trust the library to behave in a predictable manner, while still being able to load the security updates. The minor version bundles all these updates so that they can also be loaded in one big patch window.
Unattended CSR
[req] prompt = no distinguished_name = dn req_extensions = ext input_password = PASSPHRASE [dn] CN = www.feistyduck.com emailAddress = webmaster@feistyduck.com O = Feisty Duck Ltd L = London C = GB [ext] subjectAltName = DNS:www.mydomain.com,DNS:mydomain.com
openssl req -new -config fd.cnf -key fd.key -out fd.csr
openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr
OpenSSL Commands
openssl version openssl version -d
Show Certificate content
openssl s_client -connect www.islief.com:443 CTRL-D
Test HTTP
openssl s_client -connect aws.islief.com:443 HEAD / HTTP/1.0 Host: aws.islief.com
(After the HTTP Headers use an empty line)
Downloading Certificates
echo | openssl s_client -connect aws.islief.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > download.crt
Print Certificate Values
openssl x509 -in download.crt -noout -text openssl x509 -in download.crt -noout -subject -issuer -startdate -enddate
Print Certificate Issuer and Subject
for CERT in $(ls -1 *.crt) ;do echo ${CERT};openssl x509 -in ${CERT} -noout -text -issuer -subject;done
https://www.sslshopper.com/certificate-decoder.html
openssl x509 -in certificate.crt -text -noout openssl verify -CAfile root.crt node.crt openssl x509 -in node.crt -fingerprint -sha256
Do private key and certificate match
openssl rsa -in [privatekey] -check openssl pkey -in [privatekey] -pubout -outform der | sha256sum openssl x509 -in [certificate] -pubkey |openssl pkey -pubin -pubout -outform der | sha256sum
Engines
openssl info -enginesdir
GNUTLS
gnutls-cli
gnutls-serv
certtool
ocsptool
srptool
p11tool
gnutls-cli-debug
psktool
TLS Validation
When certificates expire they should be renewed. Qualys SSL LABS will not score certificates that are expired. When the recommendations in this document are followed the score in Qualys SSL LABS should be an A or a B, when it’s lower something is wrong in the TLS setup. https://www.ssllabs.com/ssltest/analyze.html?d=www.janmg.com&hideResults=on&latest
Testssl.sh
https://testssl.sh/ https://testssl.sh/openssl-rfc.mappping.html
SSLYZE
https://github.com/nabla-c0d3/sslyze
Mozilla Configuration
Mozilla has a Server Configuration Generator for webservers like Apache and NGINX with recommended SSL Configurations. https://wiki.mozilla.org/Security/Server_Side_TLS
These web servers can terminate TLS connections and forward services to other web services. For instance, Apache HTTPD can be used to terminate SSL connections by using MOD_SSL and MOD_REDIRECT to serve Apache Tomcat.
HTTP Webserver Security
Mozilla Observatory Mozilla has an observatory with TLS or HTTP headers to scan for common security configuration omissions. https://observatory.mozilla.org
HTTP Headers https://www.owasp.org/index.php/List_of_useful_HTTP_headers Content-Security-Policy X-Frame-Options X-XSS-Protection:1; mode=block https://wiki.mozilla.org/Security/Guidelines/Web_Security https://securityheaders.io/?q=janmg.com&hide=on&followRedirects=on
Strict-Transport-Security All of our sites are behind TLS, the only thing we have to figure out how operators like Swisscom and Ooredoo have put a reversed proxy in front of our application. Those solutions might be killed if we enable this header.
X-Content-Type-Options Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.
Content-Security-Policy
Often set to allow everything, resources should be loaded from one domain, but with multiple virtualhosts the resources might be served from another domain. Inlining Javascript will be impossible due to the frameworks used. So it will be difficult to come up with a good policy.
X-Frame-Options Obsolete if CSP frame-ancestors is implemented. Current Portal1 uses iframe’s for deeplinks, mainly the BO Analytics, but served through the same Apache server.
X-XSS-Protection All browsers already implement an XSS auditor and it’s active by default. Only if it is disabled, the header will switch it on again.
Public-Key-Pins Will be impossible to keep up-to-date with the current certificate system from operators, the key updating will fail and the site will be unavailable for a long time.
Content-Security-Policy https://content-security-policy.com/ add_header Content-Security-Policy "default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self'; connect-src 'self'; img-src 'self'; ";
CORS Cross Origin. When some resources come from other domains. XMLHttpRequest Access-Control-Allow-Origin https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS http://enable-cors.org/ Preflight request using HTTP Method OPTIONS 12.5 Sub Resource Integrity https://www.w3.org/TR/SRI/ With subresource integrity, additional resources like CSS or JS can only load when the integrity hashes are included in the HTML page. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity <script type="text/javascript" src="/js/script.js"
integrity="sha512-5h4b3yOdQ+…3cOoj9kw==">
</script> curl -s https://website/js/script.js | openssl dgst -sha512 -binary | openssl base64 -A
Cookies
HTTPOnly
Secure
NGINX HTTP Headers
server_tokens off; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST'; add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type'; add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
HAPROXY HTTP Headers
http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" http-response set-header X-Content-Type-Options "nosniff" http-response set-header X-Frame-Options "DENY" http-response set-header X-XSS-Protection "1; mode=block" http-response set-header Referrer-Policy "strict-origin" http-response set-header Content-Security-Policy "default-src 'none'; base-uri 'none'; style-src 'self'; script-src 'self'; object-src 'none'; img-src 'self'; media-src 'none'; form-action 'none'; frame-src 'self'; frame-ancestors 'none'; font-src 'self'; connect-src 'self'"
DNS
DANE
_443._tcp IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
https://check.sidnlabs.nl/dane/
13.2 CAA
@ IN CAA 0 issue "letsencrypt.org"
DNSSEC
/etc/bind/zone/janmg.com
cd /var/bind/
dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE janmg.com
dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE janmg.com
dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha256sum | cut -b 1-16) -N INCREMENT -o janmg.com -t /etc/bind/zone/janmg.com service named restart dnssec-dsfromkey -2 -f janmg.com.signed janmg.com
dig A janmg.com. @localhost +noadditional +dnssec +multiline
dig +dnssec +short @localhost janmg.com
https://dnssec-debugger.verisignlabs.com/janmg.com
Additional Topics
Where is crypto
Asics delid, netlist
Fpga bitstream
Hawkeye
Aes slideshow
Fpga opentitan
Son, arx, feistel
Caliptra
Joe Grant
Blackberry
Telecom
GSM
A5/1 A5/2 A5/3 A5/4
DES AES
GPRS
UMTS
LTE
Tetra
TEA1 ... TEA7
https://www.cryptomuseum.com/crypto/algo/tea/1.htm
Attacks
Man in the Middle sslstrip or mitmproxy
Security Issues and Attacks https://tools.ietf.org/html/rfc7457 downgrade attack (TLS_FALLBACK_SCSV)
FREAK Side-channel attacks ECC / Weil_restriction https://www.owasp.org/images/d/d8/OWASP_SSL_20131128_preso.pdf
Year Name Attack Against CVE
2001 Fluhrer, Mantin and Shamir RC4 2002 Padding Oracle Padding Oracle 2004 Dual_EC_DRBG Backdoor Random Generator 2009 Renegotiation CVE-2009-3555 2011 StartSSL Command Injection CVE-2014-0411 2011 Beast IV CVE-2011-3389 2012 Flame Time Compression 2012 Crime Compression details-on-the-crime-attack 2013 Breach Compression 2013 Lucky 13 CBC, timing side-channel 2014 Triple Handshake CVE-2014-1295 2014 Heartbleed SSLv3 2014 Poodle Padding Oracle SSLv3 CVE-2014-3566 2015 Freak Export grade CVE-2015-0204 2015 LogJam Export grade CVE-2015-0204 2016 Drown Downgrade RSA CVE-2016-0800 2016 Heist Compression 2016 SLOTH MD5 CVE-2015-7575 2016 Sweet32 Cipher Collision 64 bit block ciphers. DES, 3DES, IDEA, Blowfish CVE-2016-2183, CVE-2016-6329 2017 Shattered
SHA1 Collision SHA1
Crime, Breach, Heist: decrypt payloads by manipulating the file compression
Life span of a cipher
Encryption algorithms depend on the amount of computation to encrypt or decrypt when you have the key, versus the amount of computation power needed to break without the key. Over time computing power increases and theoretical and partial practical methods reduce the time from infinity to reasonable amount of time and computing resources. Over time faster and cheaper ways of breaking the cipher are found.
RC4 has a weak key schedule WIFI encryption WEP and WPA-TKIP are very weak and can be cracked in realtime. reuses the 24 bit IV’s and allows for , the secret key can be found in 15 minutes, because the IV is repeated after . RC4 used in WPA-TKIP is a cipher with very low computational requirements. There are several known attacks so that it can be broken at wirespeed.
For RC4, the following 8 attacks where published Roos's biases,Biased outputs, Fluhrer, Mantin and Shamir,Klein's attack (Broke WEP in 2001), Combinatorial problem, Royal Holloway attack, Bar-mitzvah attack, NOMORE attack DES published in 1973, is broken in 2017 with rainbow tables in under 25 seconds.
https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology
| Date | Year | Event |
|---|---|---|
| 15 May | 1973 | NBS publishes a first request for a standard encryption algorithm |
| 27 August | 1974 | NBS publishes a second request for encryption algorithms |
| 17 March | 1975 | DES is published in the Federal Register for comment |
| August | 1976 | First workshop on DES |
| September | 1976 | Second workshop, discussing mathematical foundation of DES |
| November | 1976 | DES is approved as a standard |
| 15 January | 1977 | DES is published as a FIPS standard FIPS PUB 46 |
| June | 1977 | Diffie and Hellman argue that the DES cipher can be broken by brute force.<ref name="dh-exh"/> |
| 1983 | DES is reaffirmed for the first time | |
| 1986 | Videocipher II, a TV satellite scrambling system based upon DES, begins use by HBO | |
| 22 January | 1988 | DES is reaffirmed for the second time as FIPS 46-1, superseding FIPS PUB 46 |
| July | 1991 | Biham and Shamir rediscover differential cryptanalysis, and apply it to a 15-round DES-like cryptosystem. |
| 1992 | Biham and Shamir report the first theoretical attack with less complexity than brute force: differential cryptanalysis. However, it requires an unrealistic 247 chosen plaintexts. | |
| 30 December | 1993 | DES is reaffirmed for the third time as FIPS 46-2 |
| 1994 | The first experimental cryptanalysis of DES is performed using linear cryptanalysis (Matsui, 1994). | |
| June | 1997 | The DESCHALL Project breaks a message encrypted with DES for the first time in public. |
| July | 1998 | The EFF's DES cracker (Deep Crack) breaks a DES key in 56 hours. |
| January | 1999 | Together, Deep Crack and distributed.net break a DES key in 22 hours and 15 minutes. |
| 25 October | 1999 | DES is reaffirmed for the fourth time as FIPS 46-3, which specifies the preferred use of Triple DES, with single DES permitted only in legacy systems. |
| 26 November | 2001 | The Advanced Encryption Standard is published in FIPS 197 |
| 26 May | 2002 | The AES becomes effective |
| 26 July | 2004 | The withdrawal of FIPS 46-3 (and a couple of related standards) is proposed in the Federal Register<ref>Template:Cite web</ref> |
| 19 May | 2005 | NIST withdraws FIPS 46-3 (see Federal Register vol 70, number 96) |
| April | 2006 | The FPGA-based parallel machine COPACOBANA of the Universities of Bochum and Kiel, Germany, breaks DES in 9 days at a $10,000 hardware cost.<ref name="copacobana-2006">S. Kumar, C. Paar, J. Pelzl, G. Pfeiffer, A. Rupp, M. Schimmler, "How to Break DES for Euro 8,980". 2nd Workshop on Special-purpose Hardware for Attacking Cryptographic Systems—SHARCS 2006, Cologne, Germany, April 3–4, 2006.</ref> Within a year software improvements reduced the average time to 6.4 days. |
| Nov. | 2008 | The successor of COPACOBANA, the RIVYERA machine, reduced the average time to less than a single day. |
| August | 2016 | The Open Source password cracking software hashcat added in DES brute force searching on general purpose GPUs. Benchmarking shows a single off the shelf Nvidia GeForce GTX 1080 Ti GPU costing US$1000 recovers a key in an average of 15 days (full exhaustive search taking 30 days). Systems have been built with eight GTX 1080 Ti GPUs which can recover a key in an average of under 2 days.<ref>Template:Cite web</ref> |
| July | 2017 | A chosen-plaintext attack utilizing a rainbow table can recover the DES key for a single specific chosen plaintext 1122334455667788 in 25 seconds. A new rainbow table has to be calculated per plaintext. A limited set of rainbow tables have been made available for download.<ref>Template:Cite web</ref> |
CA Breach
StuxNet, Duqu
Comodo (2011)
DigiNotar (2011)
Turktrust (2012)
Passwords
Algorithms
https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm
Argon2, Bcrypt and Pbkdf2
PBKDF2 RSA RFC 8018
BCrypt Blowfish
SCrypt
Linux Passwords
Shadow
https://github.com/shadow-maint/shadow/search?q=--crypt-method&unscoped_q=--crypt-method
$1 = MD5 hashing algorithm. $2 =Blowfish Algorithm is in use.
$2a=eksblowfish Algorithm $5 =SHA-256 Algorithm $6 =SHA-512 Algorithm
PAM
/etc/pam.d/common-password
HTTP Authorization Header
The header “Authorization” header for user password authentication has three modes, one basic where the “username:password” is based encoded. And one Digest where the username and password are MD5 hashed with a nonce for randomness. Digest Client request (username "Mufasa", password "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
Bearer comes from OAuth2
SAML2
JWT
https://jwt.io
RFC 7520 JOSE JSON Object Signing and Encryption
JSON Web Signature (JWS)
JSON Web Encryption (JWE)
JSON Web Key (JWK)
JSON Web Algorithm (JWA)
JSON Web Token (JWT)
Python
Authlib, jose, pyjwt, python-jose, JWCrypto
Secure Storage and Functions
TPM, HSM, Secure Elements, OP-TEE
RSA PKCS11
Block Mode and Forward Secrecy
IV Initialization Vector
Padding
Others
Key negotiation DH Ecliptic Curve / Prime pairs
Curve Issues
Export Grade DHE
SSH
SSH Communication
Version 1, 1.3, 1.5
Version 2
OpenSSH
ssh -v
https://www.sftp.net/specification
channels
Sch
Port forwarding
X-Forwarding
hardening
sshd_config
ssh key agent
key format
authorized_keys
putty, securecrt, mindterm
windows openssh in terminal
ftp / ftps is ftp over ssl, Microsoft IIS
Azure
Login-AzureRmAccount
Get-AzureRmSubscription
Select-AzureRmSubscription -SubscriptionName "janmg-azure"
$VirtualMachine = Get-AzureRmVM -ResourceGroupName "janmg-k8s" -Name "k8s-master-61270158-0"
$sshPublicKey = Get-Content "$env:USERPROFILE\Documents\janmg.pub"
$VirtualMachine = Add-AzureRmVMSshPublicKey -VM $VirtualMachine -KeyData
Wireguard
wg-quick v.s. wg (format of allowed address is different)
first allowedip is it's own tunnel address.
keys exchanged before hand
0.0.0.0/0 is everything, it's the default route
0.0.0.0/1 and 128.0.0.0/1 are also everything, but more specific, therefor overriding the default if set.
windows and android client
UDP/51920
ProtonVPN support for Wireguard
Server Example
[Interface] PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk= ListenPort = 51820 [Peer] PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg= AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
Client Example
[Interface] PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE= [Peer] PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw= Endpoint = 192.95.5.69:51820 AllowedIPs = 0.0.0.0/0
The client example can be converted to a QR code with qrencode for easy installation on an android instance.
PGP
Sending and receiving encrypted emails to others. https://futureboy.us/pgp.html
PGP is Pretty Good Privacy introduced by Phil Zimmermann
GPG is GNU Privacy Guard is an implementation of OpenPGP
OpenPGP is the standard RFC4880 describing e.g. the v4 fileformats.
Install
yum install gnupg apt-get install rng-tools systemctl start rngd useradd -m our_user chmod o+rw $(tty)su - our_user chmod o+rw $(tty) must be run before using su to our_user otherwise the gpg agent won’t work, you won’t be able to enter your password with gpg
Generate new key pairs
gpg --gen-key Please select what kind of key you want: (1) RSA and RSA (default) What keysize do you want? (2048) Key is valid for? (0) 1y Real name: janmg support Email address: our_user@us.com Comment: janmg support group
gpg --full-generate-key gpg --list-secret-keys gpg --export -a --output public.asc jan@janmg.com gpg --export -a --output public.pgp E8D557EDF7369B9FBC856E7C856FE6E99E21D7FC
pem2openpgp jan@janmg.com < private-key.pem | gpg --import gpg: key 3B1945D29AC3FBDA: public key "jan@janmg.com" imported gpg: key 3B1945D29AC3FBDA: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1
Publishing
Export key in ASCII format to upload on webserver
gpg --export -a user@us.com -----BEGIN PGP----- AAA... -----END PGP-----
upload to key servers.
gpg --keyserver pgp.mit.edu --send-keys 27B88533 gpg: sending key 27B88533 to hkp server pgp.mit.edu
File Encryption
Obtain the customer's public key and import it. If they send the key in ascii format, write to a file and import.
gpg --import customer.pub
Or if the you have a keyserver
gpg --keyserver pgp.mit.edu --search-keys our_user@customer.com
(or you can specify the fingerprint if they give it to you)
gpg --keyserver pgp.mit.edu --recv-keys <FINGERPRINT>
You can verify and see what keys have been imported
gpg --list-keys
Encrypt the file. In this example, the receiver of the encrypted file will be user@customer.com and the encrypted file is called testfile.
gpg --encrypt --sign -a -r user@customer.com our_user@us.com testfile
A new file will be created, called testfile.asc. It is readable as ASCII (the -a flag does this) so it can be pasted into an email. If you want to encrypt as a binary, don't use the -a flag. In this case the extension is .gpg and it's a binary file.
Decryption
gpg <encrypted file>
GPG will know what to do assuming the keys are imported. Exporting Keys for backup
gpg --export -a -o mypublickey.txt user@us.com gpg --export-secret-key -a -o myprivatekey.txt our_user@us.com
Corporate firewall blocking the keyservers may be problematic, but if they also listen to port 80 they can be accessed
hkp://keyserver.ubuntu.com:80
The keys for ubuntu are also available with a webbrowser.
http://keyserver.ubuntu.com/
Programming
JAVA
Java 6 supports up to TLSv1.0, Java 6 is end of public updates.
The Java security property jdk.tls.disabledAlgorithms has a list of disallowed protocols. For instance MD5withRSA has been disabled since Java 8. These security properties can be edited.
Before Java 8u161 (JDK-8189377), the Java security policy file did not include a policy to use the strongest encryption. A separate download of JCE provides security policies to enable these. Java Cryptography Extension (JCE) contain Unlimited Strength Jurisdiction Policy Files
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
An alternative to JCE is the Bouncy Castle project that provides lightweight API’s for cryptography.
Jasypt was another alternative encryption library, Since version 1.9.2 from February 2014 it is unmaintained.
Java 9 to support ALPN / HTTP/2 http://openjdk.java.net/jeps/244
Jetty ALPN can add support when bootstapped in the classpath. It uses Google Conscrypt which builds on BoringSSL which is a fork of OpenSSL
http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html
Javascript
https://www.misterpki.com/cryptojs/
Python
https://pycryptodome.readthedocs.io
Golang JOSE
JWT Tokens relies on JWS signing and JWE encryption with JWK keys. JWE consists of 5 parts. One is to describe the algorithms, one is the list of recipients. The recipient uses his own RSA key to decrypt the CEK, which is the symmetric key to decrypt the payload.
jose-util
Python
from jwcrypto import jwk, jwe
from jwcrypto.common import json_decode
with open("testfile.jwe", "rb") as jwefile:
enc = jwefile.read()
print(enc)
jwetoken = jwe.JWE()
jwetoken.deserialize(enc)
with open("rsa.key", "rb") as pemfile:
key = jwk.JWK.from_pem(pemfile.read())
jwetoken.decrypt(key)
payload = jwetoken.payload