TLS: Difference between revisions

From Braindump
Jump to navigation Jump to search
No edit summary
 
(89 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://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 24: Line 21:
|
|
|-
|-
|Asymettric Key pairs
|Asymmetric Key pairs
|
|RSA < 829, ECC < 224 bits
|RSA (use 2048 bit keys or higher)
|RSA (use 2048 bit keys or higher)
|ECDHE, secp256r1
|ECDHE, secp256r1
Line 51: 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 70: 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 76: 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.
 
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/).


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.
In January 2020 a chosen prefix attach https://sha-mbles.github.io/ was published.
With the message authentication (integrity) the receiver can verify the message is not altered.


* key agreement and key distribution.
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.


* hash functions
Keccak won the NIST competition (Aug 2015), now subset referred to as SHA-3
* message authentication codes.
* signature schemes


* Symmetric ciphers (shared key)
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.
* block ciphers (and modes of operation)
 
* stream ciphers
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.


* Asymmetric ciphers (public private key pair)
https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions


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 ====
1992 as <nowiki>RFC 1321</nowiki>


https://www.youtube.com/watch?v=ncL2Fl6prH8 (The Enigma Code)
* 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).


* Asymmetric primitives
=== HMAC ===
* 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.
Encrypt the hash with a common/shared key.


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/
AES Challenge Response


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


https://en.wikipedia.org/wiki/Modular_exponentiation
== 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.


=== Cipher Suites ===
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.
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
A symmetric session key can be exchanged which is the same for encrypting and decrypting. This is less computational intensive.
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.
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.
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.
With the message authentication (integrity) the receiver can verify the message is not altered.
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
* key agreement and key distribution.


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7
* hash functions
* message authentication codes.
* signature schemes


http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf
* Symmetric ciphers (shared key)
* block ciphers (and modes of operation)
* stream ciphers


=== Key Exchange ===
* Asymmetric ciphers (public private key pair)
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
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.
[DHE]
 
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/


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


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
https://en.wikipedia.org/wiki/Modular_exponentiation
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
https://github.com/crypto101/crypto101.github.io/raw/master/Crypto101.pdf


Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication
== Symmetric Ciphers ==
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSA
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
{| class="wikitable"
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.
|+RSA Groups and key length in bits
Modern ciphers are AES, Camellia, ChaCha20 and less common Aria and Seed
!Group
!Key bit length
|-
|1
|768
|-
|2
|1024
|-
|5
|1536
|-
|14
|2048
|-
|15
|3072
|-
|16
|4096
|-
|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
=== 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)


≥ 2030 128 3072 3072 256
=== 3DES Cipher ===
≫ 2030 192 7680 7680 384 ⋙ 2030 256 15360 15360 512
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.


EU - ECRYPT CSA Algorithms, key size and protocols report
http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf
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
256 15360
512
ECDLP ℓ(q) 256 512
Pairing ℓ(pᵏⁿ)
ℓ(p), ℓ(q) 6144
256 15360
512


US - Commercial National Security Algorithm (CNSA) Suite
http://bench.cr.yp.to/results-sign.html
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.
AES has a key length of 128, 192 or 256bit
Function Algorithm NIST
AES does 10 rounds of 4 transformations
(SECRET) CNSA
• ByteSub (S-Box Transformation)
(TOP SECRET)
• ShiftRow
Encryption AEAD AES-128-GCM
• MixColumn
AES-128-CCM AES-256-GCM
• AddRoundKey
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


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.


IETF Cryptographic Algorithms
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.
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.
Modern hardware implement instructions to speed up AES (intel AES-NI) or SHA-256/SHA-512 (intel AVX1/AVX2, RDRAND and RDSEED)
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.
e.g. PCLMULQDQ for GCM
IETF RFC 8017 is the best reference for PKCS #1 v2.2. Function Algorithm Parameters
e.g. SHA256MSG2 for SHA
(SECRET) Parameters
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni
(TOP SECRET)
Intel has hardware acceleration for encryption built-in processors, the feature flags are
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305
MMX,SSE2,XMM6
Key Exchange ECDH
https://software.intel.com/sites/default/files/article/402097/intel-sha-extensions-white-paper.pdf
DH Curve25519 Curve448
https://wiki.alpinelinux.org/wiki/Custom_Kernel
Digital Signature EdDSA
CAMELLIA -- avx2, avx, aes-ni
XMSS
CHACHA20 -- avx2, neon
LMS Ed25519
CAST5 – avx
XMSS
CAST6 – avx
LMS Ed448
TWOFISH – avx
XMSS
SERPENT -- avx2, avx, sse2
LMS
SHA1 -- avx2, ssse3, neon, spe
Key Derivation HKDF SHA-256
SHA2 -- avx2
SHA3-256 SHA-384
SHA256 -- ssse3, neon, spe
SHA3-384
SHA512 -- avx2, ssse3, neon
 
POLY1305 -- avx2
NIST FIPS 197 – Advanced Encryption Standard (AES)  
GHASH -- pclmulqdq (part of aes-ni), vmx (power8)
AES -- aes-ni, neon, vmx (power8), spe
NIST SP 800-38D – Galois/Counter Mode (GCM) and GMAC
CRC32 -- pclmulqdq, sse, neon, vmx (power8)
CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)
NIST SP 800-38C – The CCM Mode for Authentication and Confidentiality
Brute force, side-channel attacks, some rounds broken, still secure
 
NIST SP 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
Hashing
MD5 and SHA1 are broken. Use SHA-2 (SHA256, SHA384 or SHA512) or SHA-3.
NIST FIPS 186-4 – Digital Signature Standard (DSS)  
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.
NIST FIPS 180-4 – Secure Hash Standard (SHS)  
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.
NIST FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)  
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.
NIST FIPS 202 – SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
Poly1305 key broken down in 16 chunks[?]. Poly1305 is a cryptographic message authentication code (MAC) RFC 7539
 
NISP SP 800-185 - SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash
=== Asymmetric Ciphers ===
http://www.crypto-it.net/eng/theory/index.html
Commercial National Security Algorithm (CNSA) Suite
 
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.
IETF RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2
 
https://www.ibm.com/think/topics/cryptography-history
IETF RFC 7539 – ChaCha20 and Poly1305 for IETF Protocols
 
'''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
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)  


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


Deprecated Legacy 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.
Scheme Strength Direction
{| class="wikitable"
RC4, MD2, MD5, SHA-1 Broken Shall be forbidden
|+RSA Groups and key length in bits
< 2048-bit RSA, MODP < 112 Shall be forbidden
!Group
< 255 bit ECC < 128 Shall be forbidden
!Key bit length
3DES, Blowfish, etc.
!Public PEM in bytes
(All block ciphers with less
|-
than 128-bit block length) < 112 Shall be forbidden
|1
SSLv3, TLS 1.0, TLS 1.1, DTLS 1.0 Broken Shall be forbidden
|768
HMAC-MD5 Broken Shall be forbidden
|
CBC-mode Broken Shall be phased out
|-
IND-CPA encryption
|2
(encryption without integrity) Broken Shall be phased out
|1024
Key exchange without PFS Broken Shall be phased out
|272
RSAES-PKCS1-v1_5,
|-
RSASSA-PKCS-v1_5 Broken Shall be phased out
|5
SHA-224, SHA3-224 112 Shall be phased out
|1536
HMAC-SHA1, SHA-1 PRF 128 Shall be phased out
|
ECRYPT CSA Algorithms, key size and protocols report 2018
|-
|14
BSI TR-02102-1 - Cryptographic Mechanisms: Recommendations and Key Lengths
|2048
 
|451
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.
|15
• For signature algorithms, a good choice is to use ECDSA or EdDSA with a strong curve. See recommended algorithms for more information.
|3072
• For key exchange, a good choice is to use ECDH with a strong curve. Ephemeral ECDH offers perfect forward secrecy.
|625
• 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.
|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
|
|}


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.
=== RSA ===
• 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 ===
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.  
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
RSA Competition (no more prizes after 2007)
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.
https://en.wikipedia.org/wiki/RSA_Factoring_Challenge
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://en.wikipedia.org/wiki/RSA_numbers
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
RSA-250 decimals / 829bits was factored in February 2020 by Fabrice Boudot, Pierrick Gaudry, Aurore Guillevic, Nadia Heninger, Emmanuel Thomé, and Paul Zimmermann.


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-4.pdf?__blob=publicationFile
RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937


https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
64135289477071580278790190170577389084825014742943447208116859632024532344630238623598752668347708737661925585694639798853367 × 33372027594978156556226010605355114227940760344767554666784520987023841729210037080257448673296881877565718986258036932062711


Mozilla OpenSSH Guidelines
=== ASN.1 ===
https://infosec.mozilla.org/guidelines/openssh.html
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
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)  
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.693-202102-I!!PDF-E&type=items
 
OpenSSH
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
  }


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


Only IKEv2 and ESP is recommended. IKEv1 and AH should not be used.
ASN1.IO provides a playground and there are some other online decoders


=== IKEv2 Recommended Algorithms ===
https://asn1.io/
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 ===
http://www.crypto-it.net/eng/asymmetric/rsa.html
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.
=== 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)


Other relevant source of information NIST 800-77 Rev. 1 (Draft), BSI TR-02102-3 and ANSSI DAT-NT-003-EN.
=== Curves ===
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.
Elliptic Curve Digital Signature Algorithm (ECDSA) (SECP
Elliptic-curve Diffie–Hellman (ECDH)
Ed25519 and Ed448 (EdDSA)
X25519 and X448 (ECDH/EdDH)


https://www.coreinfrastructure.org/
https://crypto.stackexchange.com/questions/80137/understanding-example-of-ecdsa-p256/80139#80139


https://www.coreinfrastructure.org/programs/badge-program
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.


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


== Asymmetric Ciphers ==
https://neuromancer.sk/std/nist/P-256
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://neuromancer.sk/std/network


=== RSA ===
=== 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


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


RSA Competition (no more prizes after 2007)
SHA-1 the message authentication


https://en.wikipedia.org/wiki/RSA_Factoring_Challenge
TLSv1.3 (draft-ietf-tls-tls13 section-9.1) from March 2018 must support at minimum


https://en.wikipedia.org/wiki/RSA_numbers
TLS13_AES_128_GCM_SHA256 and should support


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


RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937
TLS13_CHACHA20_POLY1305_SHA256


64135289477071580278790190170577389084825014742943447208116859632024532344630238623598752668347708737661925585694639798853367 × 33372027594978156556226010605355114227940760344767554666784520987023841729210037080257448673296881877565718986258036932062711
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


=== Origin of Certificates ===
https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report
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.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7


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.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf


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


=== ASN.1 ===
[IV] Random
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.
[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.


DER Format
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.
  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
A good overview of different recommendations is given by https://www.keylength.com/en/compare/
https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/


ASN1.IO provides a playground and there are some other online decoders
Government usage often requires a higher security level (192–256) and sometimes the use of specific algorithms.


https://asn1.io/
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.


http://www.crypto-it.net/eng/asymmetric/rsa.html
https://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html


=== HSM ===
Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication
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 
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSAUS -  


http://wiki.ncryptoki.com/MainPage.ashx


=== OpenSSL ===
NIST SP 800-57 Recommendation for Key Management
openssl genrsa -out private-key.pem 4096
{| class="wikitable"
openssl rsa -in private-key.pem -text -noout
|+
openssl asn1parse -in private-key.pem
!Date
openssl rsa -in private-key.pem -pubout -out public-key.pem
!Minimum Strength RSA
openssl asn1parse -in public-key.pem
!Discrete Logarithm
openssl dgst -sha256 -hex ranger_1.8.1-0.2_all.deb
!Elliptic Curve
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
|< 2030
openssl base64 -d -in signature -out testsign.sha256
|112
openssl dgst -sha256 -verify public-key.pem -signature testsign.sha256 ranger_1.8.1-0.2_all.deb
|2048
|224
|-
|≥ 2030
|128
|3072
|256
|-
|≫ 2030
|192
|7680
|384
|-
|⋙ 2030
|256
|15360
|512
|}


openssl pkeyutl -sign -inkey private-key.pem -in file -out sig
==== EU - ECRYPT CSA Algorithms, key size and protocols report ====
openssl pkeyutl -sign -in file -inkey private-key.pem -out sig -pkeyopt md:sha256
{| class="wikitable"
openssl pkeyutl -verifyrecover -in sig -inkey private-key.pem
|+
openssl pkeyutl -verify -in file -sigfile sig -inkey private-key.pem
!Parameter
 
!
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
!Near Term
openssl ca -cert ca.crt -keyfile ca.key -in host.csr -out public.crt
!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
|
|-
|
|
|
|
|
|}


openssl x509 -noout -modulus -in public.crt | openssl sha256
==== US CNSA 1.0 ====
openssl rsa -noout -modulus -in private-key.pem | openssl sha256
{| class="wikitable"
cat public-key.pem | base64 -d | openssl asn1parse -inform DER -i -strparse 19
!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


Finite Field DH P-384


https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm
≥ 3072


=== DSA ===
Digital Signature ECDSA
...


=== Curves ===
RSA P-384


Elliptic Curve Digital Signature Algorithm (ECDSA)
≥ 3072
Elliptic-curve Diffie–Hellman (ECDH)
Ed25519 and Ed448 (EdDSA)
X25519 and X448 (ECDH/EdDH)
https://neuromancer.sk/std/nist/P-256


https://neuromancer.sk/std/network
Hash SHA2 SHA-384


== Symmetric Ciphers ==
For new deployments, Elliptic Curve Cryptography is recommended instead of RSA and finite field Diffie-Hellman.
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 ===
Function Algorithm NIST
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)
 
(SECRET) CNSA


=== 3DES Cipher ===
(TOP SECRET)
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 ===
Encryption AEAD AES-128-GCM
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.
AES-128-CCM AES-256-GCM


http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf
Key Exchange ECDH


http://bench.cr.yp.to/results-sign.html
DH Curve P-256


AES has a key length of 128, 192 or 256bit
2048 MODP Curve P-384
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.
3072 MODP


https://www.youtube.com/watch?v=mlzxpkdXP58
Digital Signature ECDSA
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.


RSA Curve P-256


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.
RSA-2048 Curve P-384
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)
RSA-3072
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
Hashing SHA SHA-256
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 ===
SHA3-256
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.
SHAKE128 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.
MAC HMAC
https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions


==== MD5 ====
KMAC
1992 as <nowiki>RFC 1321</nowiki>


* In 1996, a full collision was reported, and cryptographers recommended replacing MD5 with a different cryptographic hash function such as SHA-1.
CMAC
* 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 ===
GMAC SHA-256


AES Challenge Response
KMAC128


=== Secure Protocols ===
AES-128
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.


IANA has assigned the default port TCP/80 for HTTP and TCP/443 for HTTPS.
AES-128 SHA-384


Other protocols like SMTP for email can negotiate StartSSL and switch on encryption over an established TCP connection.
=== Post Quantum Crypto ===
https://www.chelpis.com/post/nist-publishes-new-standards-for-quantum-safe-encryption-and-digital-signatures-ml-kem-ml-dsa-slh


OSI Model Internet Model Internet Protocols Secure version
ISO/IEC/18033-2
Application Application HTTP, Telnet, FTP HTTPS, SSH, SFTP


Presentation
NIST SP 800-56A, NISTSP800-56B cryptographic key-establishment


Session
NIST SP 800-208 Leighton-Micali Signature (LMS) , stateful hash-based signatures


Transport Transport TCP, UDP TLS, DTLS
FIPS186 and digital signatures


Network Network IP IPsec
CNSA 2.0 Commercial National Security Algorithm Suite
Datalink Link Ethernet, WIFI 802.1X, WPA
{| class="wikitable"
|+
!
!
!
!
|-
|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.


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


All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
IETF RFC 8017 is the best reference for PKCS #1 v2.2.
Function Algorithm Parameters
Version Date Security
SSLv1 Netscape 1994 Never released
SSLv2 Netscape 1995 Vulnerable
SSLv3 Netscape 1996 Vulnerable
TLSv1.0 IETF RFC 2246


1999 Header Compression is broken.
Function Algorithm Parameters


TLS 1.0 may be needed for older clients like Java 6, Windows 7/Server 2008, IE 8 or Android 4
(SECRET) Parameters


TLSv1.1 IETF RFC 4346
(TOP SECRET)
 
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305


2006 Quickly replaced by TLSv1.2
Key Exchange ECDH


TLSv1.2 IETF RFC 5246
DH Curve25519 Curve448


2008 Good for modern clients
Digital Signature EdDSA


TLSv1.3 IETF RFC8446
XMSS


2018 Introduces features like 0-RTT, removes legacy ciphers
LMS Ed25519


https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols
LMS Ed448
 
LMS Key Derivation HKDF SHA-256


https://tls13.xargs.org/
SHA3-256 SHA-384


=== TLS protocol ===
==== NIST ====
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.
NIST FIPS 197 – Advanced Encryption Standard (AES)
The most important values negotiated are
 
• TLS version to use
NIST SP 800-38D – Galois/Counter Mode (GCM) and GMAC
• Verify hashing of public/private key (X.509 certificate)
• Asymmetric key
NIST SP 800-38C – The CCM Mode for Authentication and Confidentiality
• Exchange symmetric session keys
• Negotiate stream/block cipher to encrypt the payload.
NIST SP 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
• 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.
NIST FIPS 186-4 – Digital Signature Standard (DSS)  
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.
NIST FIPS 180-4 – Secure Hash Standard (SHS)
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.
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)  


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


=== SSH ===
Deprecated Legacy Algorithms
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
Scheme Strength Direction


=== IPsec ===
RC4, MD2, MD5, SHA-1 Broken Shall be forbidden
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.
< 2048-bit RSA, MODP < 112 Shall be forbidden
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)
< 255 bit ECC < 128 Shall be forbidden


Phase I, Negotiate Setting, e.g. with IKE
3DES, Blowfish, etc.


Phase II, Establish connection.
(All block ciphers with less than 128-bit block length) < 112 Shall be forbidden


https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
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


=== IKEv1 ===
Key exchange without PFS Broken Shall be phased out
Oakley protocol and ISAKMP. RFC 2409 obsoleted by IKEv2


=== IKEv2 ===
RSAES-PKCS1-v1_5, RSASSA-PKCS-v1_5 Broken Shall be phased out
RFC 7296


IKEv2 adds EAP authentication
SHA-224, SHA3-224 112 Shall be phased out
IKEv2 adds MOBIKE
HMAC-SHA1, SHA-1 PRF 128 Shall be phased out
IKEv2 adds NAT traversal
ECRYPT CSA Algorithms, key size and protocols report 2018
IKEv2 adds tunnel alive detection
IKE key exchange


SPD Security Policy
BSI TR-02102-1 - Cryptographic Mechanisms: Recommendations and Key Lengths
SAD Security Association.


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


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


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
=== Recommended Algorithms ===
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.
Key Exchange (KEX) curve25519-sha256
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-----
ecdh-sha2-nistp256
MII…==
-----END CERTIFICATE-----


LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t
ecdh-sha2-nistp384


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
Encryption (Cipher) aes128-gcm@openssh.com
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.
aes256-gcm@openssh.com
 
chacha20-poly1305@openssh.com


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.
Hostkey format ecdsa-sha2-nistp256
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
ecdsa-sha2-nistp384
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.
User Authentication publickey + MFA
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/
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


openssl genpkey
Other relevant source of information are BSI TR-02102-4 and NIST IR 7966.
openssl genrsa -aes128 -out fd.key 2048
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-4.pdf?__blob=publicationFile
openssl rsa -text -in fd.key


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


=== File format ===
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
DER is an ASN.1 file format. PEM is a DER in Base 64.
Keys can be


1. DER ASN.1
Mozilla OpenSSH Guidelines


2. SSLeay format (used by OpenSSL)
https://infosec.mozilla.org/guidelines/openssh.html
BSI TR-02102-4 - Cryptographic Mechanisms: Recommendations and Key Lengths Part 4 – Use of Secure Shell (SSH)  


3. PKCS#8 / RFC5208
NIST IR 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH)
OpenSSH


4. PKCS#7 as supported by Java Keytool
For TLS see also BSI TR-02102-2: Use of Transport Layer security:


5. PKCS#12 PFX or P12, certificate chain, used commonly by Microsoft and as method to import private keys into a Java Keystore
Only IKEv2 and ESP is recommended.


=== SAN ===
=== IKEv2 Recommended Algorithms ===
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
Encryption ENCR_AES_GCM_16
https://wiki.cacert.org/FAQ/subjectAltName


=== Certificate Authority ===
ENCR_CHACHA20_POLY1305
ROOT CA


https://cabforum.org/
Pseudorandom Function PRF_HMAC_SHA2_256


* Server Cert WG
PRF_HMAC_SHA2_384
* Code Signing Cert WG
* S/MIME Cert WG
* Net-Sec WG


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


https://certificate.transparency.dev/howctworks/
Diffie-Hellman Group Curve25519 (group 31)


https://datatracker.ietf.org/doc/html/rfc6962
256-bit random ECP group (group 19)


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.
384-bit random ECP group (group 20)


=== TPM 2.0 ===
Authentication method Digital Signature (method 14) with ECDSA or RSASSA-PSS
Attestation


=== IEEE 802.1AR ===
=== ESP Recommended Algorithms ===
Encryption ENCR_AES_GCM_16


Secure Device Identity
ENCR_CHACHA20_POLY1305


https://1.ieee802.org/security/802-1ar/
Authentication AUTH_HMAC_SHA2_256_128


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


=== BRSKI ===
More information and the complete list of the criteria can be found in the Badge Program github repository.
Vendor certificates
 
https://www.coreinfrastructure.org/


ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)
https://www.coreinfrastructure.org/programs/badge-program


Autonomic Control Plane
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md


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


=== self signed certificate ===
OpenSC is the SoftHSM, their pkcs11-tool can be used
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
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
http://wiki.ncryptoki.com/MainPage.ashx


-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/ssl/certs/docker-registry -e REGISTRY_HTTP_TLS_KEY=/etc/ssl/private/docker-registry
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'


/etc/sysconfig/docker
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


--insecure-registry myregistrydomain.com:5000
creating a key pair


boot2docker
pkcs11-tool -l -p ${p11pin} -k --id ${keyid} --label "key-1" --key-type rsa:4096
echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile
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


=== Namecheap ===
importing a private key
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 ===
openssl genrsa -out csf0.key 2048
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.
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}


certbot certonly --standalone --email ${MAIL} --agree-tos -d ${DOMAIN}
exporting public key


cd /etc/letsencrypt/live/
pkcs11-tool -l -p ${p11pin} --list-objects
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type pubkey -o csf0.der


cat privkey.pem fullchain.pem > combined.pem
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type privkey -o private_key.pem


X3 Root
=== OpenSSL ===
https://wiki.openssl.org/index.php/OpenSSL_3.0


https://www.identrust.com/support/downloads
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


Convert from DER to PEM and then from P7B to Cert
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 -inform der -in trustidrootx3_chain.p7b -out root.p7b
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


openssl pkcs7 -print_certs -in root.p7b -out root.pem
https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm


https://letsencrypt.org/certificates/
== TLS Transport Layer Security ==


=== TLS Origins ===
docker volume create letsencrypt
[[File:TLS History.png|thumb|TLS History]]
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
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.
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;


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


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.
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/
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
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.
Adobe www.adobe.com/security/approved-trust-list.htm


Mozilla Overview of All CA-Related Mozilla Documentation
=== SSL vs TLS ===
Mozilla Root Certificate Program
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.
Microsoft aka.ms/RootCert
Microsoft Root Certificate Program


Google dev.chromium.org/Home/chromium-security/root-ca-policy
SSL was standardized by Netscape based on ITU-T X.500 and RSA PKCS standards. TLS is the successor specified under IETF.


Apple www.apple.com/certificateauthority/ca_program.html
All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
 
{| class="wikitable"
Oracle www.oracle.com/technetwork/java/javase/javasecarootcertsprogram-1876540.html
|+
!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/


Linux includes the Mozilla NSS services which comes with a Root CA’s usually installed in /etc/ssl
https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
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
=== TLS protocol ===
TLS 1.3 was in state AUTH48*R with the last author review being done before release
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.
https://www.rfc-editor.org/cluster_info.php?cid=C357
The most important values negotiated are
https://tools.ietf.org/html/draft-ietf-tls-tls13-28
• TLS version to use
https://tools.ietf.org/html/rfc8446
• Verify hashing of public/private key (X.509 certificate)
Firefox 63 and Chrome 70 in October 2018 will support TLS 1.3 as 0x0304. Older versions support Draft 28 as 0x7F1C.
• 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.


https://github.com/mozilla/gecko-dev/blob/.../security/nss/lib/ssl/sslproto.h
=== TLS Certificate Profiles ===
https://hg.mozilla.org/mozilla-central/
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.  
OpenSSL version 1.1.1 from September 2018 supports TLSv1.3
{| class="wikitable"
include/openssl/tls1.h
|+
NGINX 1.13.* compiled with --with-openssl-opt=enable-tls1_3
!Version
and configured with ssl_protocols TLSv1.3; and ssl_ciphers TLS13-AES-128-GCM-SHA256
!Specification
 
!Date
'''Wireshark'''
!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.
 
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.


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


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.
-----BEGIN CERTIFICATE-----
MII…==
-----END CERTIFICATE-----


https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t


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


=== Windows ===
=== TLS Termination ===
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
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.


UseStrongCrypto
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


=== Linux ===
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.
Linux kernel supports TPM and SHA/AES
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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto
https://gchq.github.io/CyberChef/


=== Redhat Enterprise Linux ===
openssl genpkey
Redhat is using the NSS utils for certificate management
openssl genrsa -aes128 -out fd.key 2048
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
openssl rsa -text -in fd.key
yum install ca-certificates


cd /etc/pki/ca-trust/source/anchors/
modulus
publicExponent (65537)
privateExponent
prime1
prime2
exponent1
exponent2
coefficient


update-ca-trust extract
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


/etc/pki/tls/certs/
=== TLS Handshake ===
certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert
After the initial TCP handshake (3 way SYN - SYN/ACK – ACK). TLS uses a 4-way handshake (ClientHello - ServerHello - ServerKey – ClientKey).


vi /etc/openldap/ldap.conf
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_REQCERT never
TLS 1.3 can use 0-RTT to reduce the roundtrips and the version is negotiated as a list.


=== Alpine Linux ===
https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL#The_SSL_Handshake
apk add ca-certificates
+  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.


/usr/local/share/ca-certificates/
[] Indicates messages protected using keys derived from traffic_secret_N
https://blog.cloudflare.com/introducing-tls-1-3/


update-ca-certificates
TCP Fast Open, TLS False Start


/etc/ssl/certs/
=== 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.


/usr/bin/c_rehash /etc/ssl/certs
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.


WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
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.


rm -rf /etc/ssl/certs/ca-certificates.crt
A full URL should contain the schema defines if TLS should be negotiated first.


update-ca-certificates
schema://domainname:[port]/


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


cURL
'''Tunnel Socks over TLS'''


wget
https://wiki.archlinux.org/title/HTTP_tunneling#Using_corscrew_and_HTTP_CONNECT


Qt
=== ROOT CA ===
Root program, truststore


OpenSSH
=== Namecheap ===
Namecheap offers certificates through CA’s like Symantec Verisign, Geotrust and Comodo.


Apache Traffic Manager
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.


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


TianoCore/EDKII
=== 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.


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


=== JAVA ===
cd /etc/letsencrypt/live/
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 ===
cat privkey.pem fullchain.pem > combined.pem
Convert between formats


'''KEYTOOL'''
X3 Root


keytool -keystore janmg.jks -list
https://www.identrust.com/support/downloads


'''P7B'''
Convert from DER to PEM and then from P7B to Cert


keytool -keystore janmg.jks -exportcert -alias janmg1 > janmg.p7b
openssl x509 -inform der -in trustidrootx3_chain.p7b -out root.p7b


keytool -printcert -v -file janmg.p7b
openssl pkcs7 -print_certs -in root.p7b -out root.pem


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


openssl x509 -text -inform DER -in janmg.p7b


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


openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt
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;


openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt
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 PEM -in janmg.crt
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.


'''DER / XER'''
=== 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


'''Keystore to P12'''
openssl genrsa -aes256 -out ca.key 4096


keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
openssl req -subj '/CN=JANMG_ROOT_CA' -new -x509 -days 3652 -key ca.key -out ca.crt


openssl pkcs12 -info -in janmg.p12


openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key


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


'''P12 to Keystore'''
openssl req -subj '/CN=hostname' -new -key host.key -out host.csr


openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -CAkey ca.key -out host.crt
keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12


'''Merge private key and chain'''
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


cat privkey.pem fullchain.pem > combined.pem
openssl rsa -in host.key -out host.key


'''JRUBY'''
This prints the certificate as text


jruby-openssl
openssl x509 -in ca.crt -noout -text
https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol


GO crypto/tls
This copies the files to the right directories for Redhat


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


=== HAPROXY ===
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -set_serial "0x$(openssl rand -hex 16)" -CAkey ca.key -out host.crt
/etc/haproxy/haproxy.cfg
 
    tune.ssl.default-dh-param 2048
== Local Certificates ==
    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
Browsers follow CA/Browser and therefor local webservers can not have certificates relevant in the local scope.
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets


    ssl-server-verify none
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.
    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://cabforum.org/uploads/CA-Browser-Forum-BR-v2.0.1.pdf
    bind :::80 v4v6 tfo
    mode http
    redirect scheme https code 301 if !{ ssl_fc }


frontend https-in
7.1.2.7.12 Subscriber Certificate Subject Alternative Name
    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 ===
https://iotsecurityfoundation.org/router-and-iot-device-vulnerabilities-solutions-to-a-design-flaw/
LDAPS


cat root.pem chain.pem > root-intermediate.pem
https://specs.manysecured.net/suib/
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem


dn: cn=config
# Address of the local device
changetype: modify
# Browser
replace: olcTLSCertificateFile
# Certificate trust
olcTLSCertificateFile: /etc/openldap/certs/cert.pem


dn: cn=config
==== MDNS ====
changetype: modify
mdns-scan
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem


  ldapmodify -Y EXTERNAL -H ldapi:/// -f certs.ldif
  Resolve-DnsName philips-hue.local
  dig -p 5353 philips-hue.local @224.0.0.251


=== SSL Libraries ===
https://www.gabriel.urdhr.fr/2019/04/02/llmnr-mdns-cli-lookup/
https://www.feistyduck.com/library/openssl%2dcookbook/


  1995 SSLeay (by Eric A. Young and Tim J. Hudson)
  apk add avahi
  1998 OpenSSL
  service avahi-daemon start
  2003 GnuTLS
  avahi-browse -a
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.
=== 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://hg.mozilla.org/projects/nss
-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/ssl/certs/docker-registry -e REGISTRY_HTTP_TLS_KEY=/etc/ssl/private/docker-registry


=== OpenSSL ===
/etc/sysconfig/docker
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.


https://www.openssl.org/source/
--insecure-registry myregistrydomain.com:5000


Version State Introduced Last version
boot2docker
0.9.8 deprecated Jul 2005 0.9.7m (February 23, 2007)
echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile
1.0.0 deprecated Mar 2010 1.0.0t (December 3, 2015)
1.0.1 deprecated Mar 2012 1.0.1u (Sep 22, 2016) Redhat 7
1.0.1e-51.el7_2
1.0.2 supported Jan 2015 1.0.2n (Dec 7, 2017) LTS
1.1.0 supported Aug 2016 1.1.0g
1.1.1 May 2018 Pre6 First version to support TLS 1.3
3.0.0 Q4 2020 Redesign with providers


https://wiki.openssl.org/index.php/TLS1.3
== Other encrypting protocols ==


https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
=== SSH ===
 
SSH has defined it’s own protocols similar to TLS. It’s using the same components and negotiations like Keyexchange, Encryption and IV.
wget https://www.openssl.org/source/openssl-3.0.8.tar.gz
Since 2006 the version of the SSH Protocol should be SSHv2 only.
tar xvzf openssl-3.0.8.tar.gz
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.
cd openssl-3.0.8/
 
perl Configure
Putty format, OpenSSH format
perl configdata.pm --dump
 
perl Configure no-deprecated no-ssl no-des
=== IPsec ===
perl configdata.pm --dump
[[File:IPsec IKE.png|thumb]]
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
[[File:Ipsec-ike2.png|thumb]]
IPsec originates as header for IPv6 and has been ported as protocol on IPv4.


https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/openssl/openssl-3.1.5-r5.log
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.


Configration options don't seem to matter
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.


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


=== Unattended CSR ===
Phase I, Negotiate Setting, e.g. with IKE


[req]
Phase II, Establish connection.
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://docs.opnsense.org/manual/how-tos/ipsec-s2s.html


openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr
=== IKEv1 ===
Initial Key Exchange


=== OpenSSL Commands ===
RFC 2409 obsoleted by IKEv2
openssl version


openssl version -d
Oakley protocol and ISAKMP.


Show Certificate content
=== IKEv2 ===
RFC 7296


openssl s_client -connect www.islief.com:443
IKEv2 adds EAP authentication
IKEv2 adds MOBIKE
IKEv2 adds NAT traversal
IKEv2 adds tunnel alive detection
IKE key exchange


CTRL-D
SPD Security Policy
SAD Security Association.


Test HTTP
== Certificates ==


openssl s_client -connect aws.islief.com:443
=== File format ===
DER is an ASN.1 file format. PEM is a DER in Base 64 with ascii armor


HEAD / HTTP/1.0
1. DER ASN.1


Host: aws.islief.com
2. SSLeay format (used by OpenSSL)


(After the HTTP Headers use an empty line)
3. PKCS#8 / RFC5208


Downloading Certificates
4. PKCS#7 as supported by Java Keytool


echo | openssl s_client -connect aws.islief.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > download.crt
5. PKCS#12 PFX or P12, certificate chain, used commonly by Microsoft and as method to import private keys into a Java Keystore


Print Certificate Values
=== 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


openssl x509 -in download.crt -noout -text
https://wiki.cacert.org/FAQ/subjectAltName


openssl x509 -in download.crt -noout -subject -issuer -startdate -enddate
=== Certificate Authority ===
ROOT CA


Print Certificate Issuer and Subject
https://cabforum.org/


for CERT in $(ls -1 *.crt) ;do echo ${CERT};openssl x509 -in ${CERT} -noout -text -issuer -subject;done
* Server Cert WG
* Code Signing Cert WG
* S/MIME Cert WG
* Net-Sec WG


https://www.sslshopper.com/certificate-decoder.html
=== Certificate Transparency ===
https://crt.sh/?q=janmg.com


openssl x509 -in certificate.crt -text -noout
https://certificate.transparency.dev/howctworks/


openssl verify -CAfile root.crt node.crt
https://datatracker.ietf.org/doc/html/rfc6962


openssl x509 -in node.crt -fingerprint -sha256
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.


Do private key and certificate match
=== TPM 2.0 ===
openssl rsa -in [privatekey] -check
Attestation


openssl pkey -in [privatekey] -pubout -outform der | sha256sum
=== IEEE 802.1AR ===
openssl x509 -in [certificate] -pubkey |openssl pkey -pubin -pubout -outform der | sha256sum


=== GNUTLS ===
Secure Device Identity
gnutls-cli


gnutls-serv
https://1.ieee802.org/security/802-1ar/


certtool
IDevID


ocsptool
=== BRSKI ===
Vendor certificates


srptool
ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)


p11tool
Autonomic Control Plane


gnutls-cli-debug
https://datatracker.ietf.org/doc/html/rfc8995


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


=== TLS Validation ===
https://cabforum.org/browser-os-info/
When certificates expire they should be renewed. Qualys SSL LABS will not score certificates that are expired.
{| class="wikitable"
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
!Owner
!Root Store
Testssl.sh
!Link
 
!
https://testssl.sh/
|-
https://testssl.sh/openssl-rfc.mappping.html
|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.


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


https://github.com/nabla-c0d3/sslyze
'''TLS 1.2 Support'''


Mozilla Configuration
The versions of clients that can initiate TLSv1.2 connections should be at least.


Mozilla has a Server Configuration Generator for webservers like Apache and NGINX with recommended SSL Configurations.
• Android 4.4.2
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
• Firefox 32
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
• IE 11
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
• IE Mobile 11
Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.


Content-Security-Policy
• Java 8


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


X-Frame-Options
'''TLS 1.3 Support'''
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
TLS 1.3 was in state AUTH48*R with the last author review being done before release
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
https://www.rfc-editor.org/cluster_info.php?cid=C357
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://tools.ietf.org/html/draft-ietf-tls-tls13-28
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
rfc:8446
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 ===
Firefox 63 and Chrome 70 in October 2018 will support TLS 1.3 as 0x0304. Older versions support Draft 28 as 0x7F1C.
HTTPOnly


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


=== NGINX HTTP Headers ===
https://hg.mozilla.org/mozilla-central/
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 ===
OpenSSL version 1.1.1 from September 2018 supports TLSv1.3
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 ==
include/openssl/tls1.h


=== DANE ===
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
_443._tcp IN TLSA  2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
https://check.sidnlabs.nl/dane/
13.2 CAA
@        IN CAA          0 issue "letsencrypt.org"


=== DNSSEC ===
'''Wireshark'''
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


== Telecom ==
https://wiki.wireshark.org/TLS


==== GSM ====
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.
A5/1 A5/2 A5/3 A5/4


DES AES
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/


GPRS
Firefox needs NSS_ALLOW_SSLKEYLOGFILE=1 explicitly set during compilation or use the Firefox Developer edition.


UMTS
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format


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


==== Tetra ====
.NET Framework versions prior to 4.7
TEA1 ... TEA7


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


== Attacks ==
=== Linux ===
Linux kernel supports TPM and SHA/AES


Man in the Middle
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto
sslstrip or mitmproxy


Security Issues and Attacks
=== Redhat Enterprise Linux ===
https://tools.ietf.org/html/rfc7457
Redhat is using the NSS utils for certificate management
downgrade attack (TLS_FALLBACK_SCSV)
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


FREAK
vi /etc/openldap/ldap.conf
Side-channel attacks
ECC / Weil_restriction
https://www.owasp.org/images/d/d8/OWASP_SSL_20131128_preso.pdf


Year Name Attack Against CVE
TLS_REQCERT never
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 ===
=== Alpine Linux ===
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.
apk add ca-certificates
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
/usr/local/share/ca-certificates/


{| class="wikitable" style="font-size:85%;"
update-ca-certificates
|-
 
! Date
/etc/ssl/certs/
! Year
 
! Event
/usr/bin/c_rehash /etc/ssl/certs
|-
 
| 15 May
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
| 1973
 
| NBS publishes a first request for a standard encryption algorithm
rm -rf /etc/ssl/certs/ca-certificates.crt
|-
 
| 27 August
update-ca-certificates
| 1974
 
| NBS publishes a second request for encryption algorithms
 
|-
 
| 17 March
cURL
| 1975
 
| DES is published in the ''Federal Register'' for comment
wget
|-
 
| August
Qt
| 1976
 
| First workshop on DES
OpenSSH
|-
 
| September
Apache Traffic Manager
| 1976
 
| Second workshop, discussing mathematical foundation of DES
OpenConnect
|-
 
| November
TianoCore/EDKII
| 1976
 
| DES is approved as a standard
== Implementations ==
|-
 
| 15 January
=== Java Keystore / Truststore ===
| 1977
Convert between formats
| DES is published as a FIPS standard FIPS PUB 46
 
|-
'''KEYTOOL'''
| June
 
| 1977
keytool -keystore janmg.jks -list
| [[Whitfield Diffie|Diffie]] and [[Martin Hellman|Hellman]] argue that the DES cipher can be broken by brute force.<ref name="dh-exh"/>
 
|-
'''P7B'''
|
 
| 1983
keytool -keystore janmg.jks -exportcert -alias janmg1 > janmg.p7b
| DES is reaffirmed for the first time
 
|-
keytool -printcert -v -file janmg.p7b
|
 
| 1986
keytool -list -v -keystore janmg.jks -alias janmg1
| [[Videocipher]] II, a TV satellite scrambling system based upon DES, begins use by HBO
 
|-
openssl x509 -text -inform DER -in janmg.p7b
| 22 January
 
| 1988
'''PEM'''
| DES is reaffirmed for the second time as FIPS 46-1, superseding FIPS PUB 46
 
|-
openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt
| July
 
| 1991
openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt
| Biham and Shamir rediscover [[differential cryptanalysis]], and apply it to a 15-round DES-like cryptosystem.
 
|-
openssl x509 -text -inform PEM -in janmg.crt
|
 
| 1992
'''DER / XER'''
| 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
'''P12'''
| DES is reaffirmed for the third time as FIPS 46-2
 
|-
openssl pkcs12 -in janmg.p12 -nodes -legacy
|
 
| 1994
'''Keystore to P12'''
| The first experimental cryptanalysis of DES is performed using linear cryptanalysis (Matsui, 1994).
 
|-
keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
| June
 
| 1997
openssl pkcs12 -info -in janmg.p12
| The [[DESCHALL Project]] breaks a message encrypted with DES for the first time in public.
 
|-
openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key
| July
 
| 1998
'''VERIFY MATCH'''
| The [[Electronic Frontier Foundation|EFF]]'s [[EFF DES cracker|DES cracker]] (Deep Crack) breaks a DES key in 56 hours.
 
|-
openssl x509 -noout -modulus -in juststar.crt | openssl md5
| January
openssl rsa -noout -modulus -in janmg.key | openssl md5
| 1999
 
| Together, [[Deep Crack]] and [[distributed.net]] break a DES key in 22 hours and 15 minutes.
'''P12 to Keystore'''
|-
 
| 25 October
openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12
| 1999
keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12
| 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.
 
|-
'''Merge private key and chain'''
| 26 November
 
| 2001
cat privkey.pem fullchain.pem > combined.pem
| The [[Advanced Encryption Standard]] is published in FIPS 197
 
|-
'''JRUBY'''
| 26 May
 
| 2002
jruby-openssl
| The AES becomes effective
https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol
|-
 
| 26 July
GO crypto/tls
| 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>
NGINX
|-
| 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)
=== HAPROXY ===
 
/etc/haproxy/haproxy.cfg
DigiNotar (2011)
    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


Turktrust (2012)
    ssl-server-verify none
=== Passwords ===
    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


Algorithms
frontend http-in
    bind :::80 v4v6 tfo
    mode http
    redirect scheme https code 301 if !{ ssl_fc }


https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm
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


https://password-hashing.net/
=== OPENLDAP ===
LDAPS


Argon2, Bcrypt and Pbkdf2
cat root.pem chain.pem > root-intermediate.pem
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem


PBKDF2 RSA RFC 8018
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/cert.pem


BCrypt Blowfish
dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem


SCrypt
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


Linux Passwords
Mozilla maintains the NSS (Network Security Services) project that implements TLS and S/MIME for clients like Firefox.
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 ===
https://hg.mozilla.org/projects/nss
/etc/pam.d/common-password


=== HTTP Authorization Header ===
=== OpenSSL ===
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.
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.
Digest
Client request (username "Mufasa", password "Circle Of Life")


GET /dir/index.html HTTP/1.0
https://www.openssl.org/source/
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
https://endoflife.date/openssl
 
{| class="wikitable"
=== JWT ===
|+OpenSSL
<nowiki>https://jwt.io</nowiki>
!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


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
 
 
JSON Web Encryption (JWE)
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 Key (JWK)
https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/openssl/openssl-3.1.5-r5.log
 
JSON Web Algorithm (JWA)
 
JSON Web Token (JWT)


Python
Ubuntu


Authlib, jose, pyjwt, python-jose, JWCrypto
https://launchpadlibrarian.net/731303906/buildlog_ubuntu-oracular-amd64.openssl_3.0.13-0ubuntu4_BUILDING.txt.gz


=== Secure Storage and Functions ===
./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
TPM, HSM, Secure Elements, OP-TEE
make
sudo make install


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


Block Mode and Forward Secrecy
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.


IV Initialization Vector
=== Unattended CSR ===


Padding
[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


=== Others ===
openssl req -new -config fd.cnf -key fd.key -out fd.csr
Key negotiation DH Ecliptic Curve / Prime pairs


Curve Issues
openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr


Export Grade DHE
=== OpenSSL Commands ===


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


=== SSH ===
Show Certificate content
SSH Communication


Version 1, 1.3, 1.5
openssl s_client -connect www.islief.com:443
CTRL-D


Version 2
Test HTTP


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


ssh -v
(After the HTTP Headers use an empty line)


https://www.sftp.net/specification
Downloading Certificates


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


Sch
Print Certificate Values


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


X-Forwarding
Print Certificate Issuer and Subject


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


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


ssh key agent
openssl x509 -in certificate.crt -text -noout
openssl verify -CAfile root.crt node.crt
openssl x509 -in node.crt -fingerprint -sha256


key format
Do private key and certificate match


authorized_keys
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


putty, securecrt, mindterm
Engines
openssl info -enginesdir


windows openssh in terminal
=== GNUTLS ===
gnutls-cli


ftp / ftps is ftp over ssl, Microsoft IIS
gnutls-serv


=== Azure ===
certtool


Login-AzureRmAccount
ocsptool


Get-AzureRmSubscription
srptool


Select-AzureRmSubscription -SubscriptionName "janmg-azure"
p11tool


$VirtualMachine = Get-AzureRmVM -ResourceGroupName "janmg-k8s" -Name "k8s-master-61270158-0"
gnutls-cli-debug


$sshPublicKey = Get-Content "$env:USERPROFILE\Documents\janmg.pub"
psktool


$VirtualMachine = Add-AzureRmVMSshPublicKey -VM $VirtualMachine -KeyData
=== 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


== 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  
Comment:  janmg support group


gpg --full-generate-key
Strict-Transport-Security
gpg --list-secret-keys
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 --export -a --output public.asc jan@janmg.com
gpg --export -a --output public.pgp E8D557EDF7369B9FBC856E7C856FE6E99E21D7FC


pem2openpgp jan@janmg.com < private-key.pem | gpg --import
X-Content-Type-Options
gpg: key 3B1945D29AC3FBDA: public key "jan@janmg.com" imported
Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.
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 ===
Content-Security-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.
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.
gpg --keyserver pgp.mit.edu --send-keys 27B88533
gpg: sending key 27B88533 to hkp server pgp.mit.edu


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


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


Or if the you have a keyserver
Public-Key-Pins
gpg --keyserver pgp.mit.edu --search-keys our_user@customer.com
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 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.
Content-Security-Policy
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.
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


=== Decryption ===
=== 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
 
{| 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 <encrypted file>
GPG will know what to do assuming the keys are imported.
GPG will know what to do assuming the keys are imported.
Exporting Keys for backup
Exporting Keys for backup
  gpg --export -a -o mypublickey.txt user@us.com  
  gpg --export -a -o mypublickey.txt user@us.com  
  gpg --export-secret-key -a -o myprivatekey.txt our_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 1,899: 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"