TLS: Difference between revisions

From Braindump
Jump to navigation Jump to search
 
(77 intermediate revisions by the same user not shown)
Line 1: Line 1:


https://www.misterpki.com/cryptojs/
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.
 
https://ciphermachinesandcryptology.com/
 
https://access.redhat.com/articles/3642912


https://security.stackexchange.com/questions/216065/extracting-openssl-pre-master-secret-from-nginx#216456
IETF TLS has evolved from OSI X.509 and Netscape SSL. SSL is dead (r.i.p. 1999), long live 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.
{| class="wikitable"
{| class="wikitable"
|+
|+
Line 26: Line 21:
|
|
|-
|-
|Asymettric Key pairs
|Asymmetric Key pairs
|RSA<829, ECC<224 bits  
|RSA < 829, ECC < 224 bits  
|RSA (use 2048 bit keys or higher)
|RSA (use 2048 bit keys or higher)
|ECDHE, secp256r1
|ECDHE, secp256r1
Line 53: Line 48:
Use at minimum: TLSv1, RSA-2048 or ECDSA-256, AES-128-CBC, SHA-256
Use at minimum: TLSv1, RSA-2048 or ECDSA-256, AES-128-CBC, SHA-256


Use preferably: TLSv1.2, SHA-512, ECDHE, AES-256-GCM or better, TLSv1.3, SHA3, EC
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://security.stackexchange.com/questions/216065/extracting-openssl-pre-master-secret-from-nginx#216456
 
https://www.youtube.com/watch?v=kAaIYRJoJkc


https://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html
=== Organization certificate steps ===
=== 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
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
Line 72: Line 79:
8. Monitor your certificate expiry and replace it before it expires
8. Monitor your certificate expiry and replace it before it expires


=== Confidentiality and Integrity ===
== Confidentiality and Integrity ==
Secure protocols provide Confidentiality and Integrity.
Secure protocols provide Confidentiality and Integrity.


Line 78: Line 85:
   
   
• 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 (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.
=== 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.
== Integrity Hashing ==
Certificate private key signed with only SHA1 are marked as insecure by browsers and should be replaced by SHA256 signed certificate.  


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.
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/).
With the message authentication (integrity) the receiver can verify the message is not altered.


* key agreement and key distribution.
In January 2020 a chosen prefix attach https://sha-mbles.github.io/ was published.


* hash functions
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.
* message authentication codes.
* signature schemes


* Symmetric ciphers (shared key)
Keccak won the NIST competition (Aug 2015), now subset referred to as SHA-3
* block ciphers (and modes of operation)
* stream ciphers


* Asymmetric ciphers (public private key pair)
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.


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.
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://www.youtube.com/watch?v=ncL2Fl6prH8 (The Enigma Code)
https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions


* Asymmetric primitives
==== MD5 ====
* public key encryption
1992 as <nowiki>RFC 1321</nowiki>
* 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.
* 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).


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/
=== HMAC ===


https://www.secg.org/
Encrypt the hash with a common/shared key.


https://en.wikipedia.org/wiki/Modular_exponentiation
AES Challenge Response


=== Cipher Suites ===
=== Sign ===
Cipher Suites are combination of algorithms. Both Client and Server negotiate in the handshake what they support.
Encrypt a hash with the senders private key. The receiver can use the senders public key, to prove the message came from the sender.
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
== Asymmetric v.s. Symmetric ciphers ==
RSA the RSA key exchange and authentication
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.
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.
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.
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
A symmetric session key can be exchanged which is the same for encrypting and decrypting. This is less computational intensive.


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7
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.


http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf
* key agreement and key distribution.


=== Key Exchange ===
* hash functions
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.
* message authentication codes.
[IV] Random
* signature schemes
[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.
* Symmetric ciphers (shared key)
* block ciphers (and modes of operation)
* stream ciphers


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 keylength.com
* Asymmetric ciphers (public private key pair)
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.
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://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html
https://www.secg.org/


Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication
https://en.wikipedia.org/wiki/Modular_exponentiation
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSA
{| class="wikitable"
|+RSA Groups and key length in bits
!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
|
|}
US - NIST SP 800-57 Recommendation for Key Management


Date Minimum Strength RSA Discrete Logarithm Elliptic Curve < 2030 112 2048 2048 224
https://github.com/crypto101/crypto101.github.io/raw/master/Crypto101.pdf


≥ 2030 128 3072 3072 256
== Symmetric Ciphers ==
≫ 2030 192 7680 7680 384 ⋙ 2030 256 15360 15360 512
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


EU - ECRYPT CSA Algorithms, key size and protocols report
=== Feistel / Lucifer / DES ===
Parameter Near Term Long Term
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)
Symmetric Key Size k 128 256


Hash Output Size m 256 512
=== 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.


MAC Output Size m 128 256
=== 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)


RSA Problem ℓ(n) 3072 15360
In 2013 EU ECRYPT II has evaluated encryption strength.


Finite Field DLP ℓ(pⁿ)
http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf


ℓ(p), ℓ(q) 3072
http://bench.cr.yp.to/results-sign.html


256 15360
AES has a key length of 128, 192 or 256bit
AES does 10 rounds of 4 transformations
• ByteSub (S-Box Transformation)
• ShiftRow
• MixColumn
• AddRoundKey


512
A visual description of how AES works can be seen here.


ECDLP ℓ(q) 256 512
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.


Pairing ℓ(pᵏⁿ)
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.
ℓ(p), ℓ(q) 6144
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
256 15360
e.g. SHA256MSG2 for SHA
 
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni
512
Intel has hardware acceleration for encryption built-in processors, the feature flags are
 
MMX,SSE2,XMM6
US - Commercial National Security Algorithm (CNSA) Suite
https://software.intel.com/sites/default/files/article/402097/intel-sha-extensions-white-paper.pdf
Algorithm Parameters
https://wiki.alpinelinux.org/wiki/Custom_Kernel
Encryption AES-GCM AES-256
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


Key Exchange Elliptic Curve DH
Hashing
 
MD5 and SHA1 are broken. Use SHA-2 (SHA256, SHA384 or SHA512) or SHA-3.
Finite Field DH P-384
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


≥ 3072
=== Asymmetric Ciphers ===
http://www.crypto-it.net/eng/theory/index.html


Digital Signature ECDSA
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.


RSA P-384
https://www.ibm.com/think/topics/cryptography-history


≥ 3072
'''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


Hash SHA2 SHA-384
'''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.


For new deployments, Elliptic Curve Cryptography is recommended instead of RSA and finite field Diffie-Hellman.
'''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.
 
{| class="wikitable"
Function Algorithm NIST
|+RSA Groups and key length in bits
 
!Group
(SECRET) CNSA
!Key bit length
 
!Public PEM in bytes
(TOP SECRET)
|-
 
|1
Encryption AEAD AES-128-GCM
|768
 
|
AES-128-CCM AES-256-GCM
|-
 
|2
Key Exchange ECDH
|1024
 
|272
DH Curve P-256
|-
 
|5
2048 MODP Curve P-384
|1536
 
|
3072 MODP
|-
 
|14
Digital Signature ECDSA
|2048
 
|451
RSA Curve P-256
|-
 
|15
RSA-2048 Curve P-384
|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-3072
=== RSA ===


Hashing SHA SHA-256
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.


SHA3-256
RSA Competition (no more prizes after 2007)


SHAKE128 SHA-384
https://en.wikipedia.org/wiki/RSA_Factoring_Challenge


MAC HMAC
https://en.wikipedia.org/wiki/RSA_numbers


KMAC
RSA-250 decimals / 829bits was factored in February 2020 by Fabrice Boudot, Pierrick Gaudry, Aurore Guillevic, Nadia Heninger, Emmanuel Thomé, and Paul Zimmermann. 


CMAC
RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937


GMAC SHA-256
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


KMAC128
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.693-202102-I!!PDF-E&type=items


AES-128
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.


AES-128 SHA-384
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


https://asn1.io/


IETF Cryptographic Algorithms
http://www.crypto-it.net/eng/asymmetric/rsa.html


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.
=== DSA ===
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.
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)
IETF RFC 8017 is the best reference for PKCS #1 v2.2. Function Algorithm Parameters
 
(SECRET) Parameters
=== Curves ===
(TOP SECRET)
 
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305
Elliptic Curve Digital Signature Algorithm (ECDSA) (SECP
Key Exchange ECDH
Elliptic-curve Diffie–Hellman (ECDH)
DH Curve25519 Curve448
Ed25519 and Ed448 (EdDSA)
Digital Signature EdDSA
X25519 and X448 (ECDH/EdDH)
XMSS
 
LMS Ed25519
https://crypto.stackexchange.com/questions/80137/understanding-example-of-ecdsa-p256/80139#80139
XMSS
LMS Ed448
XMSS
LMS
Key Derivation HKDF SHA-256
SHA3-256 SHA-384
SHA3-384


NIST FIPS 197 – Advanced Encryption Standard (AES)
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.
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)


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


Deprecated Legacy Algorithms
https://neuromancer.sk/std/nist/P-256
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
https://neuromancer.sk/std/network


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.
=== Cipher Suites ===
ECDSA with P-256 or P-384 should be the first choice of signature algorithm for most applications.
Cipher Suites are combination of algorithms. Both Client and Server negotiate in the handshake what they support.
• For signature algorithms, a good choice is to use ECDSA or EdDSA with a strong curve. See recommended algorithms for more information.
Possible cipher suites are published by IANA
• For key exchange, a good choice is to use ECDH with a strong curve. Ephemeral ECDH offers perfect forward secrecy.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
• 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.
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
• 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.
RSA the RSA key exchange and authentication
• 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.
AES-128 the AES block cipher with 128 bit keys
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.
CBC cipher block chaining is the cipher mode
• 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 ===
SHA-1 the message authentication
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
TLSv1.3 (draft-ietf-tls-tls13 section-9.1) from March 2018 must support at minimum
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.
TLS13_AES_128_GCM_SHA256 and should support
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.
TLS13_AES_256_GCM_SHA384
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
TLS13_CHACHA20_POLY1305_SHA256


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-4.pdf?__blob=publicationFile
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.
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
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


Mozilla OpenSSH Guidelines
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7
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)
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf
OpenSSH


For TLS see also BSI TR-02102-2: Use of Transport Layer security:
== 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.


Only IKEv2 and ESP is recommended. IKEv1 and AH should not be used.
[IV] Random


=== IKEv2 Recommended Algorithms ===
[DHE]
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 ===
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.
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.
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.  


Other relevant source of information NIST 800-77 Rev. 1 (Draft), BSI TR-02102-3 and ANSSI DAT-NT-003-EN.
A good overview of different recommendations is given by https://www.keylength.com/en/compare/
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.
Government usage often requires a higher security level (192–256) and sometimes the use of specific algorithms.


https://www.coreinfrastructure.org/
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://www.coreinfrastructure.org/programs/badge-program
https://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html


https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication


== Asymmetric Ciphers ==
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSAUS -  
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.


=== RSA ===
NIST SP 800-57 Recommendation for Key Management
{| class="wikitable"
|+
!Date
!Minimum Strength RSA
!Discrete Logarithm
!Elliptic Curve
|-
|< 2030
|112
|2048
|224
|-
|≥ 2030
|128
|3072
|256
|-
|≫ 2030
|192
|7680
|384
|-
|⋙ 2030
|256
|15360
|512
|}


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.
==== EU - ECRYPT CSA Algorithms, key size and protocols report ====
 
{| class="wikitable"
RSA Competition (no more prizes after 2007)  
|+
!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
|
|-
|
|
|
|
|
|}


https://en.wikipedia.org/wiki/RSA_Factoring_Challenge
==== US CNSA 1.0 ====
 
{| class="wikitable"
https://en.wikipedia.org/wiki/RSA_numbers
!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 <nowiki>RFC 3526</nowiki>
|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


RSA-250 decimals / 829bits was factored in February 2020 by Fabrice Boudot, Pierrick Gaudry, Aurore Guillevic, Nadia Heninger, Emmanuel Thomé, and Paul Zimmermann. 
Finite Field DH P-384


RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937
≥ 3072


64135289477071580278790190170577389084825014742943447208116859632024532344630238623598752668347708737661925585694639798853367 × 33372027594978156556226010605355114227940760344767554666784520987023841729210037080257448673296881877565718986258036932062711
Digital Signature ECDSA


=== Origin of Certificates ===
RSA P-384
Certificates were standardized as part of the OSI Specifications created by ITU-T and ISO, which defined and OSI model and the OSI protocol stack. The model is commonly refered to, but the protocols where directly competing with IETF TCP/IP during the protocol wars.


Certificates were invented as part of the X.500 "Directory" which is the predecessor of LDAP.
≥ 3072


TLS certificates are based on ITU-T X.509v3 standards first developed for the X.500 Directory. 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 an end line.
Hash SHA2 SHA-384


Netscape SSL, of which 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. 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.
For new deployments, Elliptic Curve Cryptography is recommended instead of RSA and finite field Diffie-Hellman.


=== ASN.1 ===
Function Algorithm NIST
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.
(SECRET) CNSA


DER Format
(TOP SECRET)
  RSAPrivateKey ::= SEQUENCE {
 
  version  Version,
Encryption AEAD AES-128-GCM
  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
AES-128-CCM AES-256-GCM
https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/


ASN1.IO provides a playground and there are some other online decoders
Key Exchange ECDH


https://asn1.io/
DH Curve P-256


http://www.crypto-it.net/eng/asymmetric/rsa.html
2048 MODP Curve P-384


=== HSM ===
3072 MODP
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 
Digital Signature ECDSA


http://wiki.ncryptoki.com/MainPage.ashx
RSA Curve P-256


=== OpenSSL ===
RSA-2048 Curve P-384
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
RSA-3072
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
Hashing SHA SHA-256
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
SHA3-256
openssl ca -cert ca.crt -keyfile ca.key -in host.csr -out public.crt


openssl x509 -noout -modulus -in public.crt | openssl sha256
SHAKE128 SHA-384
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
MAC HMAC


=== DSA ===
KMAC
...


=== Curves ===
CMAC


Elliptic Curve Digital Signature Algorithm (ECDSA) (SECP
GMAC SHA-256
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
KMAC128


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.
AES-128


openssl ecparam -list_curves
AES-128 SHA-384
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
=== Post Quantum Crypto ===
https://www.chelpis.com/post/nist-publishes-new-standards-for-quantum-safe-encryption-and-digital-signatures-ml-kem-ml-dsa-slh


https://neuromancer.sk/std/network
ISO/IEC/18033-2


== Symmetric Ciphers ==
NIST SP 800-56A, NISTSP800-56B cryptographic key-establishment
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 ===
NIST SP 800-208 Leighton-Micali Signature (LMS) , stateful hash-based signatures
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 ===
FIPS186 and digital signatures
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 ===
CNSA 2.0 Commercial National Security Algorithm Suite
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)
{| class="wikitable"
 
|+
In 2013 EU ECRYPT II has evaluated encryption strength.
!
!
!
!
|-
|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.


http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf
==== 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.


http://bench.cr.yp.to/results-sign.html
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.


AES has a key length of 128, 192 or 256bit
IETF RFC 8017 is the best reference for PKCS #1 v2.2.
AES does 10 rounds of 4 transformations
Function Algorithm Parameters
• ByteSub (S-Box Transformation)
• ShiftRow
• MixColumn
• AddRoundKey


A visual description of how AES works can be seen here.
Function Algorithm Parameters


https://www.youtube.com/watch?v=mlzxpkdXP58
(SECRET) Parameters
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.


(TOP SECRET)


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.
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305
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)
Key Exchange ECDH
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
DH Curve25519 Curve448
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


== Integrity Hashing ==
Digital Signature EdDSA
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/).
XMSS


In January 2020 a chosen prefix attach https://sha-mbles.github.io/ was published.
LMS Ed25519


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.
LMS Ed448


Keccak won the NIST competition (Aug 2015), now subset referred to as SHA-3
LMS Key Derivation HKDF SHA-256


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.
SHA3-256 SHA-384


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.
==== NIST ====
NIST FIPS 197 – Advanced Encryption Standard (AES)


https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions
NIST SP 800-38D – Galois/Counter Mode (GCM) and GMAC
 
==== MD5 ====
NIST SP 800-38C – The CCM Mode for Authentication and Confidentiality
1992 as <nowiki>RFC 1321</nowiki>
 
NIST SP 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
* 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.
NIST FIPS 186-4 – Digital Signature Standard (DSS)
* 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.
NIST FIPS 180-4 – Secure Hash Standard (SHS)  
* 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).
NIST FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)
 
=== HMAC ===
NIST FIPS 202 – SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
 
AES Challenge Response
NISP SP 800-185 - SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash
 
=== Secure Protocols ===
Commercial National Security Algorithm (CNSA) Suite
Many protocols rely on a security layer to protect passwords from being sent unencrypted over a link. For plaintext protocols like HTTP, Telnet, FTP there are secure counterparts HTTPS, SSH and SFTP. Security can be wrapped in one or more of the security layers.
 
IETF RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2
IANA has assigned the default port TCP/80 for HTTP and TCP/443 for HTTPS.
 
IETF RFC 7539 – ChaCha20 and Poly1305 for IETF Protocols
Other protocols like SMTP for email can negotiate StartSSL and switch on encryption over an established TCP connection.
 
IETF RFC 7748 – Elliptic Curves for Security
OSI Model, https://www.itu.int/rec/T-REC-X.210-199311-I/en
{| class="wikitable"
IETF RFC 8032 – Edwards-Curve Digital Signature Algorithm (EdDSA)
|+
!OSI Model
IETF RFC 8391 - XMSS: eXtended Merkle Signature Scheme
!Internet Model
!Internet Protocols
IETF RFC 8554 - Leighton-Micali Hash-Based Signatures
!Secure version
|-
IETF RFC 5869 - HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
|Application
|Application
|HTTP, Telnet, FTP
|HTTPS, SSH, SFTP
|-
|Presentation
|
|
|
|-
|Session
|
|
|
|-
|Transport
|Transport
|TCP, UDP
|TLS, DTLS
|-
|Network
|Network
|IP
|IPsec
|-
|Link
|Link
|Ethernet, Wifi
|802.1X, WPA
|-
|Physical
|
|
|
|}


=== TLS Protocol ===


==== SSL vs TLS ====
Deprecated Legacy Algorithms
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.
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


All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
RSAES-PKCS1-v1_5, RSASSA-PKCS-v1_5 Broken Shall be phased out
{| class="wikitable"
 
|+
SHA-224, SHA3-224 112 Shall be phased out
!Version
HMAC-SHA1, SHA-1 PRF 128 Shall be phased out
!By
ECRYPT CSA Algorithms, key size and protocols report 2018
!Date
 
!Security
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.
|SSLv1
ECDSA with P-256 or P-384 should be the first choice of signature algorithm for most applications.
|Netscape
• For signature algorithms, a good choice is to use ECDSA or EdDSA with a strong curve. See recommended algorithms for more information.
|1994
• For key exchange, a good choice is to use ECDH with a strong curve. Ephemeral ECDH offers perfect forward secrecy.
|Never released
• 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.
|-
 
|SSLv2
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.
|Netscape
• 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.  
|1995
• 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.
|Vulnerable
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.
|SSLv3
• 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.
|Netscape
Only SSH-2 shall be supported. SSH-1 shall be disabled.
|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://tls13.xargs.org/
=== Recommended Algorithms ===
Key Exchange (KEX) curve25519-sha256


https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
ecdh-sha2-nistp256


=== TLS protocol ===
ecdh-sha2-nistp384
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 Handshake ===
Encryption (Cipher) aes128-gcm@openssh.com
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 
aes256-gcm@openssh.com


=== HTTPS ===
chacha20-poly1305@openssh.com
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]/
https://domain.name.com:443/


=== SSH ===
Hostkey format ecdsa-sha2-nistp256
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
ecdsa-sha2-nistp384


=== IPsec ===
User Authentication publickey + MFA
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.
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.
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.
Software versions no longer receiving security patches shall not be used.
Other relevant source of information are


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


Phase I, Negotiate Setting, e.g. with IKE
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf


Phase II, Establish connection.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-4.pdf?__blob=publicationFile


https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf


=== IKEv1 ===
Mozilla OpenSSH Guidelines
Oakley protocol and ISAKMP. RFC 2409 obsoleted by IKEv2


=== IKEv2 ===
https://infosec.mozilla.org/guidelines/openssh.html
RFC 7296
BSI TR-02102-4 - Cryptographic Mechanisms: Recommendations and Key Lengths Part 4 – Use of Secure Shell (SSH)


IKEv2 adds EAP authentication
NIST IR 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH)
IKEv2 adds MOBIKE
IKEv2 adds NAT traversal
OpenSSH
IKEv2 adds tunnel alive detection
IKE key exchange


SPD Security Policy
For TLS see also BSI TR-02102-2: Use of Transport Layer security:
SAD Security Association.


== Certificates ==
Only IKEv2 and ESP is recommended.


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.
=== IKEv2 Recommended Algorithms ===
Encryption ENCR_AES_GCM_16


X.509v3 certificates are 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
ENCR_CHACHA20_POLY1305
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-----
Pseudorandom Function PRF_HMAC_SHA2_256
MII…==
-----END CERTIFICATE-----


LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t
PRF_HMAC_SHA2_384


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
PRF_HMAC_SHA2_512
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.
Diffie-Hellman Group Curve25519 (group 31)


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.
256-bit random ECP group (group 19)
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
Netscape has adopted X.500 into SSL and IETF has created profiles to use X.509 certificates for instance for Webservers and Email.


Version Specification Date Security
384-bit random ECP group (group 20)
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 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.
Authentication method Digital Signature (method 14) with ECDSA or RSASSA-PSS
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/
=== ESP Recommended Algorithms ===
Encryption ENCR_AES_GCM_16


openssl genpkey
ENCR_CHACHA20_POLY1305
openssl genrsa -aes128 -out fd.key 2048
openssl rsa -text -in fd.key


modulus
Authentication AUTH_HMAC_SHA2_256_128
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.
AUTH_AES_128_GMAC
cat /proc/sys/kernel/random/entropy_avail
AUTH_AES_256_GMAC


=== File format ===
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.
DER is an ASN.1 file format. PEM is a DER in Base 64.
Keys can be


1. DER ASN.1
Other relevant source of information NIST 800-77 Rev. 1 (Draft), BSI TR-02102-3 and ANSSI DAT-NT-003-EN.


2. SSLeay format (used by OpenSSL)
The Core Infrastructure Initiative (CII)  (by the Linux Foundation) organizes "The Best Practices Badge" program, which is an open source secure development maturity model.


3. PKCS#8 / RFC5208
More information and the complete list of the criteria can be found in the Badge Program github repository.


4. PKCS#7 as supported by Java Keytool
https://www.coreinfrastructure.org/


5. PKCS#12 PFX or P12, certificate chain, used commonly by Microsoft and as method to import private keys into a Java Keystore
https://www.coreinfrastructure.org/programs/badge-program


=== SAN ===
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
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 ===
=== HSM ===
ROOT CA
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


https://cabforum.org/
OpenSC is the SoftHSM, their pkcs11-tool can be used 


* Server Cert WG
http://wiki.ncryptoki.com/MainPage.ashx
* Code Signing Cert WG
* S/MIME Cert WG
* Net-Sec WG


=== Certificate Transparency ===
apt install softhsm2 opensc
https://crt.sh/?q=janmg.com
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'


https://certificate.transparency.dev/howctworks/
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


https://datatracker.ietf.org/doc/html/rfc6962
creating a key pair


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


=== TPM 2.0 ===
importing a private key
Attestation


=== IEEE 802.1AR ===
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}


Secure Device Identity
exporting public key


https://1.ieee802.org/security/802-1ar/
pkcs11-tool -l -p ${p11pin} --list-objects
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type pubkey -o csf0.der


IDevID
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type privkey -o private_key.pem


=== BRSKI ===
=== OpenSSL ===
Vendor certificates
https://wiki.openssl.org/index.php/OpenSSL_3.0


ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)
openssl genrsa -out private-key.pem 4096
 
openssl rsa -in private-key.pem -text -noout
Autonomic Control Plane
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


https://datatracker.ietf.org/doc/html/rfc8995
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


=== self signed certificate ===
openssl x509 -noout -modulus -in public.crt | openssl sha256
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.
openssl rsa -noout -modulus -in private-key.pem | openssl sha256
echo 00 > ca.srl
cat public-key.pem | base64 -d | openssl asn1parse -inform DER -i -strparse 19
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
8.2 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
https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm


-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/ssl/certs/docker-registry -e REGISTRY_HTTP_TLS_KEY=/etc/ssl/private/docker-registry
== TLS Transport Layer Security ==


/etc/sysconfig/docker
=== TLS Origins ===
[[File:TLS History.png|thumb|TLS History]]
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.


--insecure-registry myregistrydomain.com:5000
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/.


boot2docker
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/
echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile


=== Namecheap ===
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.
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 ===
=== SSL vs TLS ===
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.
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.


certbot certonly --standalone --email ${MAIL} --agree-tos -d ${DOMAIN}
SSL was standardized by Netscape based on ITU-T X.500 and RSA PKCS standards. TLS is the successor specified under IETF.


cd /etc/letsencrypt/live/
All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
 
{| class="wikitable"
cat privkey.pem fullchain.pem > combined.pem
|+
 
!Version
X3 Root
!By
 
!Date
https://www.identrust.com/support/downloads
!Security
 
!
Convert from DER to PEM and then from P7B to Cert
|-
 
|SSLv1
openssl x509 -inform der -in trustidrootx3_chain.p7b -out root.p7b
|Netscape
 
|1994
openssl pkcs7 -print_certs -in root.p7b -out root.pem
|Never released
 
|
https://letsencrypt.org/certificates/
|-
 
|SSLv2
|Netscape
docker volume create letsencrypt
|1995
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
|Vulnerable
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
|SSLv3
docker logs nginx
|Netscape
docker exec -ti nginx /bin/bash
|1996
 
|Vulnerable
SSL as configuration statement deprecated in older version of NGINX. This should be now a separate server
|
 
|-
server {
|TLSv1.0
        location /.well-known {
|[rfc:2246 IETF RFC 2246]
            alias /var/www/html/.well-known;
|1999
        }
|Header Compression is broken
}
|may be needed for older clients like Java 6, Windows 7/Server 2008, IE 8 or Android 4
server {
|-
    listen [::]:443 ssl http2 default_server ipv6only=off;
|TLSv1.1
    server_name server.northeurope.cloudapp.azure.com;
|[rfc:4346 IETF RFC 4346]
    ssl_certificate /etc/letsencrypt/live/server.northeurope.cloudapp.azure.com/fullchain.pem; # managed by Certbot
|2006
    ssl_certificate_key /etc/letsencrypt/live/server.northeurope.cloudapp.azure.com/privkey.pem; # managed by Certbot 
|Quickly replaced by TLSv1.2
    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';
|TLSv1.2
    ssl_prefer_server_ciphers on;
|[rfc:5246 IETF RFC 5246]
    ssl_ecdh_curve secp384r1;
|2008
    ssl_dhparam /etc/nginx/dhparam.pem;
|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://tls13.xargs.org/


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.
https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
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 owns 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.
9.2 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
=== TLS protocol ===
Adobe www.adobe.com/security/approved-trust-list.htm
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
Mozilla Overview of All CA-Related Mozilla Documentation
• TLS version to use
Mozilla Root Certificate Program
• Verify hashing of public/private key (X.509 certificate)
Microsoft aka.ms/RootCert
• Asymmetric key
Microsoft Root Certificate Program
• Exchange symmetric session keys
 
• Negotiate stream/block cipher to encrypt the payload.
Google dev.chromium.org/Home/chromium-security/root-ca-policy
• 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.


Apple www.apple.com/certificateauthority/ca_program.html
=== 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.
{| class="wikitable"
|+
!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 [https://www.itu.int/rec/T-REC-X.509/en 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.


Oracle www.oracle.com/technetwork/java/javase/javasecarootcertsprogram-1876540.html
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.


Linux includes the Mozilla NSS services which comes with a Root CA’s usually installed in /etc/ssl
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'.
http://hg.mozilla.org/releases/mozilla-release/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
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.
9.3 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
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
TLS 1.3 was in state AUTH48*R with the last author review being done before release
-----BEGIN <LABEL>-----
https://www.rfc-editor.org/cluster_info.php?cid=C357
<base64>
https://tools.ietf.org/html/draft-ietf-tls-tls13-28
-----END <LABEL>-----
https://tools.ietf.org/html/rfc8446
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
-----BEGIN CERTIFICATE-----
https://hg.mozilla.org/mozilla-central/
MII…==
OpenSSL version 1.1.1 from September 2018 supports TLSv1.3
-----END CERTIFICATE-----
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'''
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t


https://wiki.wireshark.org/TLS
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 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.
=== TLS Termination ===


https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/
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.


Firefox needs NSS_ALLOW_SSLKEYLOGFILE=1 explicitly set during compilation or use the Firefox Developer edition.
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.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
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


=== Windows ===
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.
Schannel. Windows secure channel is the subsystem that deals with encryption
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.
Certmgr is the GUI for managing certificates
Certutil is the Commandline tool for managing certificates
Root CA are embedded in browsers and operating systems in a trust store.
Disabling TLS 1.0
Root CA’s use intermediate certificates for signing requests.
https://docs.microsoft.com/en-us/security/engineering/solving-tls1-problem
(backported to Server 2008 SP2)
https://tls-observatory.services.mozilla.com/static/certsplainer.html


.NET Framework versions prior to 4.7
https://gchq.github.io/CyberChef/


UseStrongCrypto
openssl genpkey
openssl genrsa -aes128 -out fd.key 2048
openssl rsa -text -in fd.key


=== Linux ===
modulus
Linux kernel supports TPM and SHA/AES
publicExponent (65537)
privateExponent
prime1
prime2
exponent1
exponent2
coefficient


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto
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


=== Redhat Enterprise Linux ===
=== TLS Handshake ===
Redhat is using the NSS utils for certificate management
After the initial TCP handshake (3 way SYN - SYN/ACK – ACK). TLS uses a 4-way handshake (ClientHello - ServerHello - ServerKey – ClientKey).
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
yum install ca-certificates


cd /etc/pki/ca-trust/source/anchors/
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.


update-ca-trust extract
TLS 1.3 can use 0-RTT to reduce the roundtrips and the version is negotiated as a list.


/etc/pki/tls/certs/
https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL#The_SSL_Handshake
certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert
+  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.


vi /etc/openldap/ldap.conf
[] Indicates messages protected using keys derived from traffic_secret_N
https://blog.cloudflare.com/introducing-tls-1-3/


TLS_REQCERT never
TCP Fast Open, TLS False Start


=== Alpine Linux ===
=== HTTPS ===
apk add ca-certificates
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.


/usr/local/share/ca-certificates/
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.


update-ca-certificates
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.


/etc/ssl/certs/
A full URL should contain the schema defines if TLS should be negotiated first.


/usr/bin/c_rehash /etc/ssl/certs
schema://domainname:[port]/


WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
https://domain.name.com:443/


rm -rf /etc/ssl/certs/ca-certificates.crt
'''Tunnel Socks over TLS'''


update-ca-certificates
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.


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


wget
The IP address from Comodo is in the range of 91.199.212.0/24.


Qt
=== 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.


OpenSSH
certbot certonly --standalone --email ${MAIL} --agree-tos -d ${DOMAIN}


Apache Traffic Manager
cd /etc/letsencrypt/live/


OpenConnect
cat privkey.pem fullchain.pem > combined.pem


TianoCore/EDKII
X3 Root


== Implementations ==
https://www.identrust.com/support/downloads


=== JAVA ===
Convert from DER to PEM and then from P7B to Cert
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


=== Java Keystore / Truststore ===
openssl x509 -inform der -in trustidrootx3_chain.p7b -out root.p7b
Convert between formats


'''KEYTOOL'''
openssl pkcs7 -print_certs -in root.p7b -out root.pem


keytool -keystore janmg.jks -list
https://letsencrypt.org/certificates/


'''P7B'''


keytool -keystore janmg.jks -exportcert -alias janmg1 > janmg.p7b
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


keytool -printcert -v -file janmg.p7b
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;


keytool -list -v -keystore janmg.jks -alias janmg1
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


openssl x509 -text -inform DER -in janmg.p7b
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.


'''PEM'''
=== 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.


openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt
echo 00 > ca.srl


openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt
openssl genrsa -aes256 -out ca.key 4096


openssl x509 -text -inform PEM -in janmg.crt
openssl req -subj '/CN=JANMG_ROOT_CA' -new -x509 -days 3652 -key ca.key -out ca.crt


'''DER / XER'''


...


'''Keystore to P12'''
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.


keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
openssl genrsa -aes256 -out host.key 2048


openssl pkcs12 -info -in janmg.p12
openssl req -subj '/CN=hostname' -new -key host.key -out host.csr


openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -CAkey ca.key -out host.crt


'''VERIFY MATCH'''
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 x509 -noout -modulus -in juststar.crt | openssl md5
openssl rsa -in host.key -out host.key
openssl rsa -noout -modulus -in janmg.key | openssl md5


'''P12 to Keystore'''
This prints the certificate as text


openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12
openssl x509 -in ca.crt -noout -text
keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12


'''Merge private key and chain'''
This copies the files to the right directories for Redhat


cat privkey.pem fullchain.pem > combined.pem
cp *.crt /etc/pki/tls/certs/


'''JRUBY'''
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.


jruby-openssl
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -set_serial "0x$(openssl rand -hex 16)" -CAkey ca.key -out host.crt
https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol


GO crypto/tls
== Local Certificates ==
Browsers follow CA/Browser and therefor local webservers can not have certificates relevant in the local scope.


NGINX
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


=== HAPROXY ===
7.1.2.7.12 Subscriber Certificate Subject Alternative Name
/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
https://iotsecurityfoundation.org/router-and-iot-device-vulnerabilities-solutions-to-a-design-flaw/
    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
https://specs.manysecured.net/suib/
    bind :::80 v4v6 tfo
    mode http
    redirect scheme https code 301 if !{ ssl_fc }


frontend https-in
# Address of the local device
    bind :::443 v4v6 tfo ssl crt /etc/letsencrypt/live/janmg.com/combined.pem alpn http/1.1,http/1.0
# Browser
    http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
# Certificate trust
    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 ===
==== MDNS ====
LDAPS
mdns-scan


cat root.pem chain.pem > root-intermediate.pem
Resolve-DnsName philips-hue.local
  dn: cn=config
  dig -p 5353 philips-hue.local @224.0.0.251
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem


dn: cn=config
https://www.gabriel.urdhr.fr/2019/04/02/llmnr-mdns-cli-lookup/
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/cert.pem


  dn: cn=config
  apk add avahi
  changetype: modify
  service avahi-daemon start
  replace: olcTLSCertificateKeyFile
  avahi-browse -a
olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem


ldapmodify -Y EXTERNAL  -H ldapi:/// -f certs.ldif
=== 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


=== SSL Libraries ===
-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/ssl/certs/docker-registry -e REGISTRY_HTTP_TLS_KEY=/etc/ssl/private/docker-registry
https://www.feistyduck.com/library/openssl%2dcookbook/


1995 SSLeay (by Eric A. Young and Tim J. Hudson)
/etc/sysconfig/docker
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.
--insecure-registry myregistrydomain.com:5000


https://hg.mozilla.org/projects/nss
boot2docker
echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile


=== OpenSSL ===
== Other encrypting protocols ==
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.


https://www.openssl.org/source/
=== 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.


https://endoflife.date/openssl
Putty format, OpenSSH format
{| class="wikitable"
 
|+OpenSSL
=== IPsec ===
!version
[[File:IPsec IKE.png|thumb]]
!support
[[File:Ipsec-ike2.png|thumb]]
!introduced
IPsec originates as header for IPv6 and has been ported as protocol on IPv4.
!last version
 
!redhat
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.
|0.9.8
 
|eol
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.
|Jul 2005
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.
|0.9.7m (February 23, 2007)
 
|
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)
|-
 
|1.0.0
Phase I, Negotiate Setting, e.g. with IKE
|eol
 
|Mar 2010
Phase II, Establish connection.
|1.0.0t (December 3, 2015)
 
|
https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
|-
 
|1.0.1
=== IKEv1 ===
|eol
Initial Key Exchange
|Mar 2012
 
|1.0.1u (Sep 22, 2016)
RFC 2409 obsoleted by IKEv2
|1.0.1e-51.el7_2
 
|-
Oakley protocol and ISAKMP.
|1.0.2
 
|eol
=== IKEv2 ===
|Jan 2015
RFC 7296
|1.0.2n (Dec 7, 2017)
 
|
IKEv2 adds EAP authentication
|-
IKEv2 adds MOBIKE
|1.1.0
IKEv2 adds NAT traversal
|eol
IKEv2 adds tunnel alive detection
|Aug 2016
IKE key exchange
|
 
|
SPD Security Policy
|-
SAD Security Association.
|1.1.1
 
|eol
== Certificates ==
|May 2018
 
|First version to support TLS 1.3
=== File format ===
|el8 1.1.1k
DER is an ASN.1 file format. PEM is a DER in Base 64 with ascii armor
|-
 
|3.0
1. DER ASN.1
|
 
|Q4 2020
2. SSLeay format (used by OpenSSL)
|Redesign with providers
 
|
3. PKCS#8 / RFC5208
|-
 
|3.1
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
|
|
|-
|3.2
|
|
|
|
|}
https://wiki.openssl.org/index.php/TLS1.3


https://www.openssl.org/docs/man3.0/man7/migration_guide.html
=== 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://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
https://wiki.cacert.org/FAQ/subjectAltName
 
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
=== Certificate Authority ===
ROOT CA


Configration options don't seem to matter
https://cabforum.org/


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.
* Server Cert WG
* Code Signing Cert WG
* S/MIME Cert WG
* Net-Sec WG


=== Unattended CSR ===
=== Certificate Transparency ===
https://crt.sh/?q=janmg.com


[req]
https://certificate.transparency.dev/howctworks/
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
https://datatracker.ietf.org/doc/html/rfc6962


openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr
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.


=== OpenSSL Commands ===
=== TPM 2.0 ===
openssl version
Attestation


openssl version -d
=== IEEE 802.1AR ===


Show Certificate content
Secure Device Identity


openssl s_client -connect www.islief.com:443
https://1.ieee802.org/security/802-1ar/


CTRL-D
IDevID


Test HTTP
=== BRSKI ===
Vendor certificates


openssl s_client -connect aws.islief.com:443
ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)


HEAD / HTTP/1.0
Autonomic Control Plane


Host: aws.islief.com
https://datatracker.ietf.org/doc/html/rfc8995


(After the HTTP Headers use an empty line)
=== 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.


Downloading Certificates
https://cabforum.org/browser-os-info/
 
{| class="wikitable"
echo | openssl s_client -connect aws.islief.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > download.crt
|+
 
!Owner
Print Certificate Values
!Root Store
 
!Link
openssl x509 -in download.crt -noout -text
!
 
|-
openssl x509 -in download.crt -noout -subject -issuer -startdate -enddate
|Adobe
 
|www.adobe.com/security/approved-trust-list.htm
Print Certificate Issuer and Subject
|
|
|-
|Mozilla
|Mozilla Root Certificate Program
|Overview of All CA-Related Mozilla Documentation
|
|-
|Microsoft
|Microsoft Root Certificate Program
|aka.ms/RootCert
|
|-
|Google
|
|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


for CERT in $(ls -1 *.crt) ;do echo ${CERT};openssl x509 -in ${CERT} -noout -text -issuer -subject;done
http://hg.mozilla.org/releases/mozilla-release/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt


https://www.sslshopper.com/certificate-decoder.html
The Chrome Browser uses the platform specific truststore. ChromeOS uses it’s own Chromium Root CA.


openssl x509 -in certificate.crt -text -noout
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.


openssl verify -CAfile root.crt node.crt
'''TLS 1.2 Support'''


openssl x509 -in node.crt -fingerprint -sha256
The versions of clients that can initiate TLSv1.2 connections should be at least.


Do private key and certificate match
• Android 4.4.2
openssl rsa -in [privatekey] -check


openssl pkey -in [privatekey] -pubout -outform der | sha256sum
• Firefox 32
openssl x509 -in [certificate] -pubkey |openssl pkey -pubin -pubout -outform der | sha256sum


=== GNUTLS ===
• IE 11
gnutls-cli


gnutls-serv
• IE Mobile 11


certtool
• Java 8


ocsptool
• Safari 7


srptool
'''TLS 1.3 Support'''


p11tool
TLS 1.3 was in state AUTH48*R with the last author review being done before release


gnutls-cli-debug
https://www.rfc-editor.org/cluster_info.php?cid=C357


psktool
https://tools.ietf.org/html/draft-ietf-tls-tls13-28


=== TLS Validation ===
rfc:8446
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/
Firefox 63 and Chrome 70 in October 2018 will support TLS 1.3 as 0x0304. Older versions support Draft 28 as 0x7F1C.
https://testssl.sh/openssl-rfc.mappping.html


SSLYZE
https://github.com/mozilla/gecko-dev/blob/.../security/nss/lib/ssl/sslproto.h


https://github.com/nabla-c0d3/sslyze
https://hg.mozilla.org/mozilla-central/


Mozilla Configuration
OpenSSL version 1.1.1 from September 2018 supports TLSv1.3


Mozilla has a Server Configuration Generator for webservers like Apache and NGINX with recommended SSL Configurations.
include/openssl/tls1.h
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
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
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
'''Wireshark'''
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
https://wiki.wireshark.org/TLS
Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.


Content-Security-Policy
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.


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.
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/


X-Frame-Options
Firefox needs NSS_ALLOW_SSLKEYLOGFILE=1 explicitly set during compilation or use the Firefox Developer edition.
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
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
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
=== Windows ===
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.
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)


Content-Security-Policy
.NET Framework versions prior to 4.7
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'; ";
UseStrongCrypto


CORS
=== Linux ===
Cross Origin. When some resources come from other domains.
Linux kernel supports TPM and SHA/AES
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 ===
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto
HTTPOnly


Secure
=== Redhat Enterprise Linux ===
Redhat is using the NSS utils for certificate management
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html


=== NGINX HTTP Headers ===
yum install ca-certificates
server_tokens off;
 
add_header X-Frame-Options SAMEORIGIN;
cd /etc/pki/ca-trust/source/anchors/
add_header X-Content-Type-Options nosniff;
 
add_header X-XSS-Protection "1; mode=block";
update-ca-trust extract
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 ===
/etc/pki/tls/certs/
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 ==
certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert


=== DANE ===
vi /etc/openldap/ldap.conf
_443._tcp IN TLSA  2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
https://check.sidnlabs.nl/dane/
13.2 CAA
@        IN CAA          0 issue "letsencrypt.org"


=== DNSSEC ===
TLS_REQCERT never
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
 
/etc/bind/zone/janmg.com
=== Alpine Linux ===
cd /var/bind/
apk add ca-certificates
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


== Telecom ==
/usr/local/share/ca-certificates/


==== GSM ====
update-ca-certificates
A5/1 A5/2 A5/3 A5/4


DES AES
/etc/ssl/certs/


GPRS
/usr/bin/c_rehash /etc/ssl/certs


UMTS
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping


LTE
rm -rf /etc/ssl/certs/ca-certificates.crt


==== Tetra ====
update-ca-certificates
TEA1 ... TEA7


https://www.cryptomuseum.com/crypto/algo/tea/1.htm


== Attacks ==


Man in the Middle
cURL
sslstrip or mitmproxy


Security Issues and Attacks
wget
https://tools.ietf.org/html/rfc7457
 
downgrade attack (TLS_FALLBACK_SCSV)
Qt
 
OpenSSH
 
Apache Traffic Manager
 
OpenConnect
 
TianoCore/EDKII


FREAK
== Implementations ==
Side-channel attacks
ECC / Weil_restriction
https://www.owasp.org/images/d/d8/OWASP_SSL_20131128_preso.pdf


Year Name Attack Against CVE
=== Java Keystore / Truststore ===
2001 Fluhrer, Mantin and Shamir RC4
Convert between formats
2002 Padding Oracle Padding Oracle
 
2004 Dual_EC_DRBG Backdoor Random Generator
'''KEYTOOL'''
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
http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/
Crime, Breach, Heist: decrypt payloads by manipulating the file compression


=== Life span of a cipher ===
keytool -keystore janmg.jks -list
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
'''P7B'''


{| class="wikitable" style="font-size:85%;"
keytool -keystore janmg.jks -exportcert -alias janmg1 > janmg.p7b
|-
 
! Date
keytool -printcert -v -file janmg.p7b
! Year
 
! Event
keytool -list -v -keystore janmg.jks -alias janmg1
|-
 
| 15 May
openssl x509 -text -inform DER -in janmg.p7b
| 1973
 
| NBS publishes a first request for a standard encryption algorithm
'''PEM'''
|-
 
| 27 August
openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt
| 1974
 
| NBS publishes a second request for encryption algorithms
openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt
|-
 
| 17 March
openssl x509 -text -inform PEM -in janmg.crt
| 1975
 
| DES is published in the ''Federal Register'' for comment
'''DER / XER'''
|-
 
| August
...
| 1976
 
| First workshop on DES
'''P12'''
|-
 
| September
openssl pkcs12 -in janmg.p12 -nodes -legacy
| 1976
 
| Second workshop, discussing mathematical foundation of DES
'''Keystore to P12'''
|-
 
| November
keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
| 1976
 
| DES is approved as a standard
openssl pkcs12 -info -in janmg.p12
|-
 
| 15 January
openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key
| 1977
 
| DES is published as a FIPS standard FIPS PUB 46
'''VERIFY MATCH'''
|-
 
| June
openssl x509 -noout -modulus -in juststar.crt | openssl md5
| 1977
openssl rsa -noout -modulus -in janmg.key | openssl md5
| [[Whitfield Diffie|Diffie]] and [[Martin Hellman|Hellman]] argue that the DES cipher can be broken by brute force.<ref name="dh-exh"/>
 
|-
'''P12 to Keystore'''
|
 
| 1983
openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12
| DES is reaffirmed for the first time
keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12
|-
 
|
'''Merge private key and chain'''
| 1986
 
| [[Videocipher]] II, a TV satellite scrambling system based upon DES, begins use by HBO
cat privkey.pem fullchain.pem > combined.pem
|-
 
| 22 January
'''JRUBY'''
| 1988
 
| DES is reaffirmed for the second time as FIPS 46-1, superseding FIPS PUB 46
jruby-openssl
|-
https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol
| July
 
| 1991
GO crypto/tls
| Biham and Shamir rediscover [[differential cryptanalysis]], and apply it to a 15-round DES-like cryptosystem.
 
|-
NGINX
|
 
| 1992
 
| Biham and Shamir report the first theoretical attack with less complexity than brute force: [[differential cryptanalysis]]. However, it requires an unrealistic 2<sup>47</sup> [[chosen plaintext]]s.
=== HAPROXY ===
|-
/etc/haproxy/haproxy.cfg
| 30 December
    tune.ssl.default-dh-param 2048
| 1993
    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
| DES is reaffirmed for the third time as FIPS 46-2
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
|-
 
|
    ssl-server-verify none
| 1994
    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
| The first experimental cryptanalysis of DES is performed using linear cryptanalysis (Matsui, 1994).
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
|-
 
| June
frontend http-in
| 1997
    bind :::80 v4v6 tfo
| The [[DESCHALL Project]] breaks a message encrypted with DES for the first time in public.
    mode http
|-
    redirect scheme https code 301 if !{ ssl_fc }
| July
 
| 1998
frontend https-in
| The [[Electronic Frontier Foundation|EFF]]'s [[EFF DES cracker|DES cracker]] (Deep Crack) breaks a DES key in 56 hours.
    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"
| January
    http-response set-header X-Content-Type-Options "nosniff"
| 1999
    http-response set-header X-Frame-Options "DENY"
| Together, [[Deep Crack]] and [[distributed.net]] break a DES key in 22 hours and 15 minutes.
    http-response set-header X-XSS-Protection "1; mode=block"
|-
    http-response set-header Referrer-Policy "strict-origin"
| 25 October
    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'"
| 1999
    default_backend app
| 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.
backend app
|-
    balance source
| 26 November
    http-request add-header X-Forwarded-Proto https
| 2001
 
| The [[Advanced Encryption Standard]] is published in FIPS 197
=== OPENLDAP ===
|-
LDAPS
| 26 May
 
| 2002
cat root.pem chain.pem > root-intermediate.pem
| The AES becomes effective
dn: cn=config
|-
changetype: modify
| 26 July
replace: olcTLSCACertificateFile
| 2004
olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem
| The withdrawal of FIPS 46-3 (and a couple of related standards) is proposed in the ''Federal Register''<ref>{{cite web|url=http://edocket.access.gpo.gov/2004/04-16894.htm |title=FR Doc 04-16894 |publisher=Edocket.access.gpo.gov |access-date=2009-06-02}}</ref>
 
|-
dn: cn=config
| 19 May
changetype: modify
| 2005
replace: olcTLSCertificateFile
| NIST withdraws FIPS 46-3 (see [https://web.archive.org/web/20080625202735/http://csrc.nist.gov/publications/fips/05-9945-DES-Withdrawl.pdf Federal Register vol 70, number 96])
olcTLSCertificateFile: /etc/openldap/certs/cert.pem
|-
 
| April
dn: cn=config
| 2006
changetype: modify
| The [[Field-programmable gate array|FPGA]]-based parallel machine [[Custom hardware attack#History|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.
replace: olcTLSCertificateKeyFile
|-
olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem
| Nov.
| 2008
| The successor of [[Custom hardware attack#History|COPACOBANA]], the RIVYERA machine, reduced the average time to less than a single day.
|-
| August
| 2016
| The Open Source password cracking software [https://hashcat.net/hashcat/ hashcat] added in DES brute force searching on general purpose GPUs. Benchmarking shows a single off the shelf Nvidia [[GeForce 10 series|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>{{Cite web | url=https://gist.github.com/epixoip/ace60d09981be09544fdd35005051505 | title=8x1080Ti.md}}</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>{{Cite web | url=https://crack.sh | title=Crack.sh &#124; the World's Fastest DES Cracker}}</ref>
|}


=== CA Breach ===
ldapmodify -Y EXTERNAL  -H ldapi:/// -f certs.ldif
StuxNet, Duqu


Comodo (2011)
=== SSL Libraries ===
https://www.feistyduck.com/library/openssl%2dcookbook/


DigiNotar (2011)
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


Turktrust (2012)
Mozilla maintains the NSS (Network Security Services) project that implements TLS and S/MIME for clients like Firefox.
=== Passwords ===


Algorithms
https://hg.mozilla.org/projects/nss


https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm
=== OpenSSL ===
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.


https://password-hashing.net/
https://www.openssl.org/source/


Argon2, Bcrypt and Pbkdf2
https://endoflife.date/openssl
 
{| class="wikitable"
PBKDF2 RSA RFC 8018
|+OpenSSL
 
!version
BCrypt Blowfish
!support
 
!introduced
SCrypt
!last version
 
!redhat
 
|-
 
|0.9.8
Linux Passwords
|eol
Shadow
|Jul 2005
https://github.com/shadow-maint/shadow/search?q=--crypt-method&unscoped_q=--crypt-method
|0.9.7m (February 23, 2007)
$1 = MD5 hashing algorithm.
|
$2 =Blowfish Algorithm is in use.
|-
$2a=eksblowfish Algorithm
|1.0.0
$5 =SHA-256 Algorithm
|eol
$6 =SHA-512 Algorithm
|Mar 2010
 
|1.0.0t (December 3, 2015)
=== PAM ===
|
/etc/pam.d/common-password
|-
 
|1.0.1
=== HTTP Authorization Header ===
|eol
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.
|Mar 2012
Digest
|1.0.1u (Sep 22, 2016)
Client request (username "Mufasa", password "Circle Of Life")
|1.0.1e-51.el7_2
 
|-
GET /dir/index.html HTTP/1.0
|1.0.2
Host: localhost
|eol
Authorization: Digest username="Mufasa",
|Jan 2015
                    realm="testrealm@host.com",
|1.0.2n (Dec 7, 2017)
                    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
|
                    uri="/dir/index.html",
|-
                    qop=auth,
|1.1.0
                    nc=00000001,
|eol
                    cnonce="0a4f113b",
|Aug 2016
                    response="6629fae49393a05397450978507c4ef1",
|
                    opaque="5ccc069c403ebaf9f0171e9517f40e41"
|
Bearer comes from OAuth2
|-
 
|1.1.1w
SAML2
|eol
 
|May 2018
=== JWT ===
|First version to support TLS 1.3
<nowiki>https://jwt.io</nowiki>
|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


RFC 7520 JOSE JSON Object Signing and Encryption
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


JSON Web Signature (JWS)
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


JSON Web Encryption (JWE)
https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/openssl/openssl-3.1.5-r5.log


JSON Web Key (JWK)
Ubuntu


JSON Web Algorithm (JWA)
https://launchpadlibrarian.net/731303906/buildlog_ubuntu-oracular-amd64.openssl_3.0.13-0ubuntu4_BUILDING.txt.gz


JSON Web Token (JWT)
./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


Python
Configuration options don't seem to matter much for OpenSSL 3.0


Authlib, jose, pyjwt, python-jose, JWCrypto
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.


=== Secure Storage and Functions ===
=== Unattended CSR ===
TPM, HSM, Secure Elements, OP-TEE


RSA PKCS11
[req]
 
prompt = no
Block Mode and Forward Secrecy
distinguished_name = dn
 
req_extensions = ext
IV Initialization Vector
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


Padding
openssl req -new -config fd.cnf -key fd.key -out fd.csr


=== Others ===
openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr
Key negotiation DH Ecliptic Curve / Prime pairs


Curve Issues
=== OpenSSL Commands ===


Export Grade DHE
openssl version
openssl version -d


https://www.cryptologie.net/article/361/nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls/
Show Certificate content


=== SSH ===
openssl s_client -connect www.islief.com:443
SSH Communication
CTRL-D


Version 1, 1.3, 1.5
Test HTTP


Version 2
openssl s_client -connect aws.islief.com:443
HEAD / HTTP/1.0
Host: aws.islief.com


OpenSSH
(After the HTTP Headers use an empty line)


ssh -v
Downloading Certificates


https://www.sftp.net/specification
echo | openssl s_client -connect aws.islief.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > download.crt


channels
Print Certificate Values


Sch
openssl x509 -in download.crt -noout -text
openssl x509 -in download.crt -noout -subject -issuer -startdate -enddate


Port forwarding
Print Certificate Issuer and Subject


X-Forwarding
for CERT in $(ls -1 *.crt) ;do echo ${CERT};openssl x509 -in ${CERT} -noout -text -issuer -subject;done


hardening
https://www.sslshopper.com/certificate-decoder.html


sshd_config
openssl x509 -in certificate.crt -text -noout
openssl verify -CAfile root.crt node.crt
openssl x509 -in node.crt -fingerprint -sha256


ssh key agent
Do private key and certificate match


key format
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


authorized_keys
Engines
openssl info -enginesdir


putty, securecrt, mindterm
=== GNUTLS ===
gnutls-cli


windows openssh in terminal
gnutls-serv


ftp / ftps is ftp over ssl, Microsoft IIS
certtool


=== Azure ===
ocsptool


Login-AzureRmAccount
srptool


Get-AzureRmSubscription
p11tool


Select-AzureRmSubscription -SubscriptionName "janmg-azure"
gnutls-cli-debug


$VirtualMachine = Get-AzureRmVM -ResourceGroupName "janmg-k8s" -Name "k8s-master-61270158-0"
psktool


$sshPublicKey = Get-Content "$env:USERPROFILE\Documents\janmg.pub"
=== TLS Validation ===
 
When certificates expire they should be renewed. Qualys SSL LABS will not score certificates that are expired.
$VirtualMachine = Add-AzureRmVMSshPublicKey -VM $VirtualMachine -KeyData
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


== PGP ==
https://testssl.sh/
Sending and receiving encrypted emails to others. https://futureboy.us/pgp.html
https://testssl.sh/openssl-rfc.mappping.html


PGP is Pretty Good Privacy introduced by Phil Zimmermann
SSLYZE


GPG is GNU Privacy Guard is an implementation of OpenPGP
https://github.com/nabla-c0d3/sslyze


OpenPGP is the standard RFC4880 describing e.g. the v4 fileformats.
Mozilla Configuration


=== Install ===
Mozilla has a Server Configuration Generator for webservers like Apache and NGINX with recommended SSL Configurations.
yum install gnupg
https://wiki.mozilla.org/Security/Server_Side_TLS
apt-get install rng-tools
   
systemctl start rngd
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. 
useradd -m our_user
== HTTP Webserver Security ==
  chmod o+rw $(tty)su - our_user
Mozilla Observatory
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
Mozilla has an observatory with TLS or HTTP headers to scan for common security configuration omissions.
https://observatory.mozilla.org


Generate new key pairs
HTTP Headers
gpg --gen-key
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Please select what kind of key you want:
Content-Security-Policy
(1) RSA and RSA (default)
X-Frame-Options X-XSS-Protection:1; mode=block
What keysize do you want? (2048)
https://wiki.mozilla.org/Security/Guidelines/Web_Security
Key is valid for? (0) 1y
https://securityheaders.io/?q=janmg.com&hide=on&followRedirects=on
Real name: janmg support
 
Email address: our_user@us.com  
Strict-Transport-Security
Comment:  janmg support group
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.


gpg --full-generate-key
X-Content-Type-Options
gpg --list-secret-keys
Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.
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
Content-Security-Policy
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 ===
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.
Export key in ASCII format to upload on webserver
gpg --export -a user@us.com
-----BEGIN PGP-----
AAA...
-----END PGP-----


upload to key servers.
X-Frame-Options
gpg --keyserver pgp.mit.edu --send-keys 27B88533
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.
gpg: sending key 27B88533 to hkp server pgp.mit.edu


=== File Encryption ===
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.


Obtain the customer's public key and import it. If they send the key in ascii format, write to a file and import.
Public-Key-Pins
gpg --import customer.pub
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.


Or if the you have a keyserver
Content-Security-Policy
gpg --keyserver pgp.mit.edu --search-keys our_user@customer.com
https://content-security-policy.com/
(or you can specify the fingerprint if they give it to you)
add_header Content-Security-Policy "default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self'; connect-src 'self'; img-src 'self'; ";
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.
==== CORS Cross Origin. ====
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.
When some resources come from other domains.


=== Decryption ===
XMLHttpRequest
gpg <encrypted file>
 
GPG will know what to do assuming the keys are imported.
Access-Control-Allow-Origin
Exporting Keys for backup
 
gpg --export -a -o mypublickey.txt user@us.com
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
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
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


hkp://keyserver.ubuntu.com:80
=== NGINX HTTP Headers ===
 
server_tokens off;
The keys for ubuntu are also available with a webbrowser.
add_header X-Frame-Options SAMEORIGIN;
 
add_header X-Content-Type-Options nosniff;
<nowiki>http://keyserver.ubuntu.com/</nowiki>
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 ===
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
 
/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
 
http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/
 
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
 
{| class="wikitable" style="font-size:85%;"
|-
! 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
| [[Whitfield Diffie|Diffie]] and [[Martin Hellman|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 2<sup>47</sup> [[chosen plaintext]]s.
|-
| 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 [[Electronic Frontier Foundation|EFF]]'s [[EFF DES cracker|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>{{cite web|url=http://edocket.access.gpo.gov/2004/04-16894.htm |title=FR Doc 04-16894 |publisher=Edocket.access.gpo.gov |access-date=2009-06-02}}</ref>
|-
| 19 May
| 2005
| NIST withdraws FIPS 46-3 (see [https://web.archive.org/web/20080625202735/http://csrc.nist.gov/publications/fips/05-9945-DES-Withdrawl.pdf Federal Register vol 70, number 96])
|-
| April
| 2006
| The [[Field-programmable gate array|FPGA]]-based parallel machine [[Custom hardware attack#History|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 [[Custom hardware attack#History|COPACOBANA]], the RIVYERA machine, reduced the average time to less than a single day.
|-
| August
| 2016
| The Open Source password cracking software [https://hashcat.net/hashcat/ hashcat] added in DES brute force searching on general purpose GPUs. Benchmarking shows a single off the shelf Nvidia [[GeForce 10 series|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>{{Cite web | url=https://gist.github.com/epixoip/ace60d09981be09544fdd35005051505 | title=8x1080Ti.md}}</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>{{Cite web | url=https://crack.sh | title=Crack.sh &#124; the World's Fastest DES Cracker}}</ref>
|}
 
=== CA Breach ===
StuxNet, Duqu
 
Comodo (2011)
 
DigiNotar (2011)
 
Turktrust (2012)
=== Passwords ===
 
Algorithms
 
https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm
 
https://password-hashing.net/
 
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 ===
<nowiki>https://jwt.io</nowiki>
 
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
 
https://www.cryptologie.net/article/361/nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls/
 
=== 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.
 
<nowiki>http://keyserver.ubuntu.com/</nowiki>
 
== 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 ===
[https://datatracker.ietf.org/doc/html/rfc7516 rfc7516]


== JOSE ==
[https://datatracker.ietf.org/doc/html/rfc7516 rfc7516]
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.
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.


Line 2,096: Line 2,563:
  jwetoken.decrypt(key)
  jwetoken.decrypt(key)
  payload = jwetoken.payload
  payload = jwetoken.payload
== 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://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
https://cabforum.org/uploads/CA-Browser-Forum-BR-v2.0.1.pdf
7.1.2.7.12 Subscriber Certificate Subject Alternative Name
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

Latest revision as of 09:17, 6 February 2025

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://security.stackexchange.com/questions/216065/extracting-openssl-pre-master-secret-from-nginx#216456

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://www.secg.org/

https://en.wikipedia.org/wiki/Modular_exponentiation

https://github.com/crypto101/crypto101.github.io/raw/master/Crypto101.pdf

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.

RSA Groups and key length in bits
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

https://asn1.io/

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

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7

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

https://www.chelpis.com/post/nist-publishes-new-standards-for-quantum-safe-encryption-and-digital-signatures-ml-kem-ml-dsa-slh

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://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-4.pdf?__blob=publicationFile

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

TLS History

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://tls13.xargs.org/

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]/

https://domain.name.com:443/

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/

  1. Address of the local device
  2. Browser
  3. 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 IKE.png
Ipsec-ike2.png

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

https://cabforum.org/

  • Server Cert WG
  • Code Signing Cert WG
  • S/MIME Cert WG
  • Net-Sec WG

Certificate Transparency

https://crt.sh/?q=janmg.com

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
Google 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

http://hg.mozilla.org/releases/mozilla-release/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt

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

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

https://launchpadlibrarian.net/731303906/buildlog_ubuntu-oracular-amd64.openssl_3.0.13-0ubuntu4_BUILDING.txt.gz 

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

https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2

/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

http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/

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

https://password-hashing.net/

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

https://www.cryptologie.net/article/361/nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls/

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

rfc7516

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.

go-jose

jose-util

Python

jwcrypto jwe 

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
Retrieved from "https://www.janmg.com/wiki/index.php?title=TLS&oldid=1622"