TLS: Difference between revisions

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


https://www.misterpki.com/cryptojs/
TLS is a protocol that uses multiple types of security algorithms to provide confidentiality and integrity over TCP. TLS is a connection layer with a handshake providing key exchange using certificates, message authentication and encryption.
 
https://ciphermachinesandcryptology.com/
 
https://access.redhat.com/articles/3642912


https://security.stackexchange.com/questions/216065/extracting-openssl-pre-master-secret-from-nginx#216456
IETF TLS has evolved from OSI X.509 and Netscape SSL. SSL is dead (r.i.p. 1999), long live TLS


TLS is a protocol that uses multiple types of security algorithms to provide confidentiality and integrity over TCP. TLS is a connection layer with a handshake providing key exchange using certificates, message authentication and encryption.
{| class="wikitable"
{| class="wikitable"
|+
|+
Line 26: Line 21:
|
|
|-
|-
|Asymettric Key pairs
|Asymmetric Key pairs
|RSA<829, ECC<224 bits  
|RSA < 829, ECC < 224 bits  
|RSA (use 2048 bit keys or higher)
|RSA (use 2048 bit keys or higher)
|ECDHE, secp256r1
|ECDHE, secp256r1
Line 55: Line 50:
Use preferably: TLSv1.3, SHA-512, ECDHE, AES-256-GCM or better, TLSv1.3, SHA3, EC
Use preferably: TLSv1.3, SHA-512, ECDHE, AES-256-GCM or better, TLSv1.3, SHA3, EC


=== Links ===
https://ciphermachinesandcryptology.com/
https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/
https://access.redhat.com/articles/3642912
https://security.stackexchange.com/questions/216065/extracting-openssl-pre-master-secret-from-nginx#216456
https://www.youtube.com/watch?v=kAaIYRJoJkc
https://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html
=== Organization certificate steps ===
=== Organization certificate steps ===
1. Appoint a responsible for creating and managing private key and guard it is a business critical secret. A RSA should be a 4096 bit key. Encrypting the key makes starting up webservices difficult
1. Appoint a responsible for creating and managing private key and guard it is a business critical secret. A RSA should be a 4096 bit key. Encrypting the key makes starting up webservices difficult
Line 72: Line 79:
8. Monitor your certificate expiry and replace it before it expires
8. Monitor your certificate expiry and replace it before it expires


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


Line 78: Line 85:
   
   
• Integrity (signing/hash/digest) provides the possibility to verify the sender. When Alice sends a signed message to Bob. Bob can verify that the message really came from Alice and not from Eve. Eve can still read the message.
• Integrity (signing/hash/digest) provides the possibility to verify the sender. When Alice sends a signed message to Bob. Bob can verify that the message really came from Alice and not from Eve. Eve can still read the message.
=== Asymmetric v.s. Symmetric ciphers ===
Key Exchange uses asymmetrical encryption with a private and public key pair. The public key can be freely shared and is used for encryption. The private key has to be kept secret. Only a party with the private key can decrypt the message.
The public key can be placed inside a certificate and only the holder of the private key can decrypt a challenge message and prove they own the private key.


A symmetric session key can be exchanged which is the same for encrypting and decrypting. This is less computational intensive.
== Integrity Hashing ==
Certificate private key signed with only SHA1 are marked as insecure by browsers and should be replaced by SHA256 signed certificate.  


The data is transmitted using symmetric encryption in data blocks. The first block is mixed with a shared initial vector (random) and encrypted with a shared secret key. This block is than used as input for the encryption of the next blocks.
Certificates contain a public key which is signed an integrity hash. Chrome, IE, Firefox, Java dropped support for SHA-1 signed certificates in 2016. SHA-1 is from 1995 and the stronger SHA-2 and SHA-3 already exist. An SHA-1 hash collision can be found by padding a document (http://shattered.io/).
With the message authentication (integrity) the receiver can verify the message is not altered.


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


* hash functions
Root certificates are shipped with browsers so those are still considered safe anchor points, but the certificates that are negotiated like intermediate certificates and normal certificates, should not be signed with SHA-1 and browsers will drop support by 2017, but you might get complaints sooner from for instance Chrome.
* message authentication codes.
* signature schemes


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


* Asymmetric ciphers (public private key pair)
Below are two pictures on how MD5 and SHA-1 process one round on 32 bit words. In MD5’s 64 rounds, A’ is calculated as function of A with B,C and D and the result is rotated and repeated.


Asymmetrical public key encryption like RSA, DSA or elliptic curve derived algorithm like ECDSA or ECDHE are computational intensive. Asymmetrical public/private key pairs are used to exchange symmetric shared secret keys.
MD5 and SHA-1 have been deprecated and newer SHA-2 and SHA-3 use more rounds and bigger blocksizes that result in longer hashes, with less chance of collisions.


https://www.youtube.com/watch?v=ncL2Fl6prH8 (The Enigma Code)
https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions


* Asymmetric primitives
==== MD5 ====
* public key encryption
1992 as <nowiki>RFC 1321</nowiki>
* public key authentication/identification schemes
* key encapsulation mechanisms


Until 2001 U.S. companies were not allowed to export strong encryption and have used deliberately weak export grade encryption by reducing the key length. These should be avoided. Anonymous key exchange should also be avoided.
* In 1996, a full collision was reported, and cryptographers recommended replacing MD5 with a different cryptographic hash function such as SHA-1.
* Early in 2004, a project began to prove that MD5 was vulnerable to a birthday attack due to the small size of the hash value at 128-bits.
* By mid-2004, an analytical attack was completed in only an hour that was able to create collisions for the full MD5.
* In 2005, a practical collision was demonstrated using two X.509 certificates with different public keys and the same MD5 hash value. Days later, an algorithm was created that could construct MD5 collisions in just a few hours.
* A year later, in 2006, an algorithm was published that used tunneling to find a collision within one minute on a single notebook computer.  
* In 2008, MD5 was officially declared “cryptographically broken” as MD5 hashes can be created to collide with trusted X.509 certificates issued by well-known certificate authorities (CAs).


For RSA and DSA use at minimum 2048 bit keys, but preferably 4092 bit. For ecliptic curves, avoid using P-256 and use Curve25519 instead. https://safecurves.cr.yp.to/
=== HMAC ===


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


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


=== Cipher Suites ===
=== Sign ===
Cipher Suites are combination of algorithms. Both Client and Server negotiate in the handshake what they support.
Encrypt a hash with the senders private key. The receiver can use the senders public key, to prove the message came from the sender.
Possible cipher suites are published by IANA
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml


For example, the TLSv1.2 mandatory cipher suite (RFC 5246 section-9) from August 2008, TLS_RSA_WITH_AES_128_CBC_SHA can be broken down into
== Asymmetric v.s. Symmetric ciphers ==
RSA the RSA key exchange and authentication
Key Exchange uses asymmetrical encryption with a private and public key pair. The public key can be freely shared and is used for encryption. The private key has to be kept secret. Only a party with the private key can decrypt the message.
AES-128 the AES block cipher with 128 bit keys
CBC cipher block chaining is the cipher mode
SHA-1 the message authentication
TLSv1.3 (draft-ietf-tls-tls13 section-9.1) from March 2018 must support at minimum
TLS13_AES_128_GCM_SHA256
and should support
TLS13_AES_256_GCM_SHA384
TLS13_CHACHA20_POLY1305_SHA256


Security protocols and algorithms depend on computational limitations (factoring of large numbers). What was considered secure 10 years ago, has weakened because computing power has increased, and researchers find (partial) methods, reducing the computing power needed to break the algorithm. Algorithms and their application are under constant evaluation and their weaknesses are theoretically, partially and fully broken and the attacks or optimized. Security researchers will publish these attacks. Criminals and state sponsored attackers don’t.
The public key can be placed inside a certificate and only the holder of the private key can decrypt a challenge message and prove they own the private key.
Algorithms are reused in different applications. SHA-1 for instance as a signature fingerprint is vulnerable to collisions. It’s possible to change signed certificates that has the same fingerprint.
Governmental recommendations on algorithms, key sizes and parameters are
EU Enisa, Germany BSI-TR-02102-2, US NIST.SP.800-78-4


https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report
A symmetric session key can be exchanged which is the same for encrypting and decrypting. This is less computational intensive.


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7
The data is transmitted using symmetric encryption in data blocks. The first block is mixed with a shared initial vector (random) and encrypted with a shared secret key. This block is than used as input for the encryption of the next blocks.
With the message authentication (integrity) the receiver can verify the message is not altered.


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


=== Key Exchange ===
* hash functions
Asymmetric ciphers are compute intensive and used for exchanging symmetric keys. Avoid using anonymous DH and Export Grade. For DHE and RSA use at least 2048 bit keys or use the new ECDHE.
* message authentication codes.
[IV] Random
* signature schemes
[DHE]


RSA and DSA calculate the public/private key once and reuses them between connections. Once this RSA key would be found, previously recorded encrypted messages can be decrypted. For forward secrecy, ECDHE calculates new key pairs for each connection.
* Symmetric ciphers (shared key)
* block ciphers (and modes of operation)
* stream ciphers


NIST (USA) and ECRYPT (EU) publishes comprehensive lists on minimum key size requirements for general purposes. They agree on a near term minimum requirement of 128-bit security. A good overview of different recommendations is given by keylength.com
* Asymmetric ciphers (public private key pair)
Government usage often requires a higher security level (192–256) and sometimes the use of specific algorithms.
The NIST minimum requirements on security levels shall always be met. 128-bit security should be used, but 112-bit algorithms such as RSA-2048 are acceptable short-term. Algorithms offering less that 112-bit security shall not be supported. If implemented, such algorithms should be disabled by default and only enabled for legacy interop reasons. Such implementations (e.g. supporting SHA-1 certificates or RSA-1024) does not offer acceptable security.


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


Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication
https://github.com/crypto101/crypto101.github.io/raw/master/Crypto101.pdf
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSA
{| class="wikitable"
|+RSA Groups and key length in bits
!Group
!Key bit length
!Public PEM in bytes
|-
|1
|768
|
|-
|2
|1024
|272
|-
|5
|1536
|
|-
|14
|2048
|451
|-
|15
|3072
|625
|-
|16
|4096
|800
|-
|19
|256-bit random Elliptic Curve Group
|
|-
|20
|384-bit random Elliptic Curve Group
|
|-
|24
|2048-bit with 256-bit Prime Order Subgroup
|
|}
US - NIST SP 800-57 Recommendation for Key Management


Date Minimum Strength RSA Discrete Logarithm Elliptic Curve < 2030 112 2048 2048 224
== 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


≥ 2030 128 3072 3072 256
=== Feistel / Lucifer / DES ===
≫ 2030 192 7680 7680 384 ⋙ 2030 256 15360 15360 512
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)


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


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


MAC Output Size m 128 256
In 2013 EU ECRYPT II has evaluated encryption strength.


RSA Problem ℓ(n) 3072 15360
http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf


Finite Field DLP ℓ(pⁿ)
http://bench.cr.yp.to/results-sign.html


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


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


512
https://www.youtube.com/watch?v=mlzxpkdXP58
AES operations are done on 128 bit blocks. Block chaining uses an initialization vector (IV) to introduce randomness to encrypted form. ECB block chaining should not be used, because the encrypted blocks still reveal the contours of the original message.


ECDLP ℓ(q) 256 512
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.
Pairing ℓ(pᵏⁿ)
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
ℓ(p), ℓ(q) 6144
e.g. SHA256MSG2 for SHA
 
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni
256 15360
Intel has hardware acceleration for encryption built-in processors, the feature flags are
 
MMX,SSE2,XMM6
512
https://software.intel.com/sites/default/files/article/402097/intel-sha-extensions-white-paper.pdf
 
https://wiki.alpinelinux.org/wiki/Custom_Kernel
US - Commercial National Security Algorithm (CNSA) Suite
CAMELLIA -- avx2, avx, aes-ni
Algorithm Parameters
CHACHA20 -- avx2, neon
Encryption AES-GCM AES-256
CAST5 – avx
CAST6 – avx
TWOFISH – avx
SERPENT -- avx2, avx, sse2
SHA1 -- avx2, ssse3, neon, spe
SHA2 -- avx2
SHA256 -- ssse3, neon, spe
SHA512 -- avx2, ssse3, neon
POLY1305 -- avx2
GHASH -- pclmulqdq (part of aes-ni), vmx (power8)
AES -- aes-ni, neon, vmx (power8), spe
CRC32 -- pclmulqdq, sse, neon, vmx (power8)
CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)
Brute force, side-channel attacks, some rounds broken, still secure


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


Finite Field DH P-384
=== Asymmetric Ciphers ===
http://www.crypto-it.net/eng/theory/index.html


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


Digital Signature ECDSA
https://www.ibm.com/think/topics/cryptography-history


RSA P-384
'''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


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


Hash SHA2 SHA-384
'''1977''': Ron Rivest, Adi Shamir and Leonard Adleman introduce the RSA public key cryptosystem. RSA public keys are created by multiplying large prime numbers, which are prohibitively difficult for even the most powerful computers to factor without prior knowledge of the private key used to create the public key.
 
{| class="wikitable"
For new deployments, Elliptic Curve Cryptography is recommended instead of RSA and finite field Diffie-Hellman.
|+RSA Groups and key length in bits
 
!Group
Function Algorithm NIST
!Key bit length
 
!Public PEM in bytes
(SECRET) CNSA
|-
 
|1
(TOP SECRET)
|768
 
|
Encryption AEAD AES-128-GCM
|-
 
|2
AES-128-CCM AES-256-GCM
|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
|
|}


Key Exchange ECDH
=== RSA ===


DH Curve P-256
RSA stands for Rivest, Shamir and Adleman, who published the PKCS crypto standards in 1977 and formed the RSA company. PKCS#1 is the RSA asymmetric public/private key which relies on the practical difficulty of factoring the product of two large prime numbers. PKCS#1 is now maintained at IETF RFC8017. The RSA Private key components can be packaged using the ASN.1 DER.


2048 MODP Curve P-384
RSA Competition (no more prizes after 2007)


3072 MODP
https://en.wikipedia.org/wiki/RSA_Factoring_Challenge


Digital Signature ECDSA
https://en.wikipedia.org/wiki/RSA_numbers


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


RSA-2048 Curve P-384
RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937


RSA-3072
64135289477071580278790190170577389084825014742943447208116859632024532344630238623598752668347708737661925585694639798853367 × 33372027594978156556226010605355114227940760344767554666784520987023841729210037080257448673296881877565718986258036932062711


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


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


SHAKE128 SHA-384
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.


MAC HMAC
DER Format
 
  RSAPrivateKey ::= SEQUENCE {
KMAC
  version  Version,
 
  modulus  INTEGER,          -- n
CMAC
  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/


GMAC SHA-256
ASN1.IO provides a playground and there are some other online decoders


KMAC128
https://asn1.io/


AES-128
http://www.crypto-it.net/eng/asymmetric/rsa.html


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


IETF Cryptographic Algorithms
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.


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.
openssl ecparam -list_curves
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.
openssl ecparam -name prime256v1 -genkey -noout -out prime256v1.pem
IETF RFC 8017 is the best reference for PKCS #1 v2.2. Function Algorithm Parameters
openssl ec -in prime256v1.pem -pubout -out prime256v1.pub
(SECRET) Parameters
openssl ec -pubin -inform PEM -in prime256v1.pub -outform DER -out prime256v1.der
(TOP SECRET)
openssl ecparam -name secp256k1 -genkey -noout -out secp256k1.pem
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305
openssl ec -in secp256k1.pem -pubout -out secp256k1.pub
Key Exchange ECDH
openssl ec -pubin -inform PEM -in secp256k1.pub -outform DER -out secp256k1.der
DH Curve25519 Curve448
 
Digital Signature EdDSA
https://neuromancer.sk/std/nist/P-256
XMSS
 
LMS Ed25519
https://neuromancer.sk/std/network
XMSS
LMS Ed448
XMSS
LMS
Key Derivation HKDF SHA-256
SHA3-256 SHA-384
SHA3-384


NIST FIPS 197 – Advanced Encryption Standard (AES)
=== Cipher Suites ===
Cipher Suites are combination of algorithms. Both Client and Server negotiate in the handshake what they support.
NIST SP 800-38D – Galois/Counter Mode (GCM) and GMAC
Possible cipher suites are published by IANA
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
NIST SP 800-38C – The CCM Mode for Authentication and Confidentiality
 
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
NIST SP 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
RSA the RSA key exchange and authentication
AES-128 the AES block cipher with 128 bit keys
NIST FIPS 186-4 – Digital Signature Standard (DSS)
CBC cipher block chaining is the cipher mode
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)


SHA-1 the message authentication


Deprecated Legacy Algorithms
TLSv1.3 (draft-ietf-tls-tls13 section-9.1) from March 2018 must support at minimum
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
TLS13_AES_128_GCM_SHA256 and should support


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.
TLS13_AES_256_GCM_SHA384
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.
TLS13_CHACHA20_POLY1305_SHA256
• 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 ===
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.
Key Exchange (KEX) curve25519-sha256
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


ecdh-sha2-nistp256
https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report


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


Encryption (Cipher) aes128-gcm@openssh.com
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf


aes256-gcm@openssh.com
== 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.  


chacha20-poly1305@openssh.com
[IV] Random


Hostkey format ecdsa-sha2-nistp256
[DHE]


ecdsa-sha2-nistp384
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.


User Authentication publickey + MFA
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.


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.
A good overview of different recommendations is given by https://www.keylength.com/en/compare/
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.
Government usage often requires a higher security level (192–256) and sometimes the use of specific algorithms.
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
The NIST minimum requirements on security levels shall always be met. 128-bit security should be used, but 112-bit algorithms such as RSA-2048 are acceptable short-term. Algorithms offering less that 112-bit security shall not be supported. If implemented, such algorithms should be disabled by default and only enabled for legacy interop reasons. Such implementations (e.g. supporting SHA-1 certificates or RSA-1024) does not offer acceptable security.


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-4.pdf?__blob=publicationFile
https://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html


https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
Ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication


Mozilla OpenSSH Guidelines
gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSAUS -


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


For TLS see also BSI TR-02102-2: Use of Transport Layer security:
==== EU - ECRYPT CSA Algorithms, key size and protocols report ====
 
{| class="wikitable"
Only IKEv2 and ESP is recommended.
|+
 
!Parameter
=== IKEv2 Recommended Algorithms ===
!
Encryption ENCR_AES_GCM_16
!Near Term
 
!Long Term
ENCR_CHACHA20_POLY1305
!
|-
|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
|
|-
|
|
|
|
|
|}


Pseudorandom Function PRF_HMAC_SHA2_256
==== US CNSA 1.0 ====
{| class="wikitable"
!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


PRF_HMAC_SHA2_384
Key Exchange Elliptic Curve DH


PRF_HMAC_SHA2_512
Finite Field DH P-384


Diffie-Hellman Group Curve25519 (group 31)
≥ 3072


256-bit random ECP group (group 19)
Digital Signature ECDSA


384-bit random ECP group (group 20)
RSA P-384


Authentication method Digital Signature (method 14) with ECDSA or RSASSA-PSS
≥ 3072


=== ESP Recommended Algorithms ===
Hash SHA2 SHA-384
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.
For new deployments, Elliptic Curve Cryptography is recommended instead of RSA and finite field Diffie-Hellman.


Other relevant source of information NIST 800-77 Rev. 1 (Draft), BSI TR-02102-3 and ANSSI DAT-NT-003-EN.
Function Algorithm NIST
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.
(SECRET) CNSA


https://www.coreinfrastructure.org/
(TOP SECRET)


https://www.coreinfrastructure.org/programs/badge-program
Encryption AEAD AES-128-GCM


https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
AES-128-CCM AES-256-GCM


== Asymmetric Ciphers ==
Key Exchange ECDH
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.
DH Curve P-256


https://www.ibm.com/think/topics/cryptography-history
2048 MODP Curve P-384


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


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


'''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 Curve P-256


=== RSA ===
RSA-2048 Curve P-384


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


RSA Competition (no more prizes after 2007)
Hashing SHA SHA-256


https://en.wikipedia.org/wiki/RSA_Factoring_Challenge
SHA3-256


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


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


RSA-250 = 2140324650240744961264423072839333563008614715144755017797754920881418023447140136643345519095804679610992851872470914587687396261921557363047454770520805119056493106687691590019759405693457452230589325976697471681738069364894699871578494975937497937
KMAC


64135289477071580278790190170577389084825014742943447208116859632024532344630238623598752668347708737661925585694639798853367 × 33372027594978156556226010605355114227940760344767554666784520987023841729210037080257448673296881877565718986258036932062711
CMAC


=== ASN.1 ===
GMAC SHA-256
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
KMAC128


ASN.1 is a packing mechanism defining a schema with variable and their types. BER is the binary packing format following a TLV Type Length Value notation. Sequence is 0x30, the length can be multiple bytes where the First bit MSB indicates if more bytes (referred to as octets). The value can be of a type for instance INTEGER, IA5String or UTF8String.
AES-128


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


http://www.crypto-it.net/eng/asymmetric/rsa.html
ISO/IEC/18033-2


=== HSM ===
NIST SP 800-56A, NISTSP800-56B cryptographic key-establishment
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 
NIST SP 800-208 Leighton-Micali Signature (LMS) , stateful hash-based signatures


http://wiki.ncryptoki.com/MainPage.ashx
FIPS186 and digital signatures


apt install softhsm2 opensc
CNSA 2.0 Commercial National Security Algorithm Suite
softhsm2-util --init-token --slot 0 --label "softhsm"
{| class="wikitable"
|+
ls -la /var/lib/softhsm/tokens/
!
!
export p11pin="1234abcd"
!
export keyid=$(uuidgen | tr -d -)
!
|-
|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.


alias pkcs11-tool='/usr/bin/pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so'
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.
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
IETF RFC 8017 is the best reference for PKCS #1 v2.2.
Function Algorithm Parameters


pkcs11-tool -l -p ${p11pin} -k --id ${keyid} --label "key-1" --key-type rsa:4096
Function Algorithm Parameters
pkcs11-tool --list-slots
 
pkcs11-tool --id ${keyid} --read-object --type pubkey -o key-1.der
(SECRET) Parameters
openssl rsa -pubin -inform DER -in key-1.der -outform PEM -out key-1.pem


importing a private key
(TOP SECRET)


openssl genrsa -out csf0.key 2048
Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305
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}
openssl rsa -in csf0.key -pubout -out csf0.pem
pkcs11-tool -l --pin ${p11pin} --write-object ./csf0.pem --type pubkey --id ${keyid}


For OP-TEE the same commands can be used, with a different module
Key Exchange ECDH


alias pkcs11-tool='/usr/bin/pkcs11-tool --module /usr/lib/libckteec.so.0'
DH Curve25519 Curve448


=== OpenSSL ===
Digital Signature EdDSA
https://wiki.openssl.org/index.php/OpenSSL_3.0


openssl genrsa -out private-key.pem 4096
XMSS
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
LMS Ed25519
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
LMS Ed448
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
LMS Key Derivation HKDF SHA-256
openssl ca -cert ca.crt -keyfile ca.key -in host.csr -out public.crt


openssl x509 -noout -modulus -in public.crt | openssl sha256
SHA3-256 SHA-384
openssl rsa -noout -modulus -in private-key.pem | openssl sha256
cat public-key.pem | base64 -d | openssl asn1parse -inform DER -i -strparse 19


https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm
==== NIST ====
NIST FIPS 197 – Advanced Encryption Standard (AES)


=== DSA ===
NIST SP 800-38D – Galois/Counter Mode (GCM) and GMAC
...
 
NIST SP 800-38C – The CCM Mode for Authentication and Confidentiality
=== Curves ===
 
NIST SP 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
Elliptic Curve Digital Signature Algorithm (ECDSA) (SECP
Elliptic-curve Diffie–Hellman (ECDH)
NIST FIPS 186-4 – Digital Signature Standard (DSS)  
Ed25519 and Ed448 (EdDSA)
X25519 and X448 (ECDH/EdDH)
NIST FIPS 180-4 – Secure Hash Standard (SHS)
 
https://crypto.stackexchange.com/questions/80137/understanding-example-of-ecdsa-p256/80139#80139
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)


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


https://neuromancer.sk/std/network
RC4, MD2, MD5, SHA-1 Broken Shall be forbidden


== Symmetric Ciphers ==
< 2048-bit RSA, MODP < 112 Shall be forbidden
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 ===
< 255 bit ECC < 128 Shall be forbidden
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 ===
3DES, Blowfish, etc.
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 ===
(All block ciphers with less than 128-bit block length) < 112 Shall be forbidden
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.
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


http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf
Key exchange without PFS Broken Shall be phased out


http://bench.cr.yp.to/results-sign.html
RSAES-PKCS1-v1_5, RSASSA-PKCS-v1_5 Broken Shall be phased out


AES has a key length of 128, 192 or 256bit
SHA-224, SHA3-224 112 Shall be phased out
AES does 10 rounds of 4 transformations
HMAC-SHA1, SHA-1 PRF 128 Shall be phased out
• ByteSub (S-Box Transformation)
ECRYPT CSA Algorithms, key size and protocols report 2018
• ShiftRow
• MixColumn
• AddRoundKey


A visual description of how AES works can be seen here.
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


https://www.youtube.com/watch?v=mlzxpkdXP58
ecdh-sha2-nistp256
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.


ecdh-sha2-nistp384


ECB reuses the IV and although the message is encrypted, the pattern is still visible. CBC (1976) doesn’t have this problem, it uses the output of the previous block as input to the next block. CBC is simple and often used.
Encryption (Cipher) aes128-gcm@openssh.com
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
aes256-gcm@openssh.com
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 ==
chacha20-poly1305@openssh.com
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/).
Hostkey format ecdsa-sha2-nistp256


In January 2020 a chosen prefix attach https://sha-mbles.github.io/ was published.
ecdsa-sha2-nistp384


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.
User Authentication publickey + MFA


Keccak won the NIST competition (Aug 2015), now subset referred to as SHA-3
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


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


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://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf


https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-4.pdf?__blob=publicationFile


==== MD5 ====
https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
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.
Mozilla OpenSSH Guidelines
* 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 ===
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


AES Challenge Response
For TLS see also BSI TR-02102-2: Use of Transport Layer security:


=== Secure Protocols ===
Only IKEv2 and ESP is recommended.
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.
=== IKEv2 Recommended Algorithms ===
Encryption ENCR_AES_GCM_16


Other protocols like SMTP for email can negotiate StartSSL and switch on encryption over an established TCP connection.
ENCR_CHACHA20_POLY1305


OSI Model, https://www.itu.int/rec/T-REC-X.210-199311-I/en
Pseudorandom Function PRF_HMAC_SHA2_256
{| class="wikitable"
|+
!OSI Model
!Internet Model
!Internet Protocols
!Secure version
|-
|Application
|Application
|HTTP, Telnet, FTP
|HTTPS, SSH, SFTP
|-
|Presentation
|
|
|
|-
|Session
|
|
|
|-
|Transport
|Transport
|TCP, UDP
|TLS, DTLS
|-
|Network
|Network
|IP
|IPsec
|-
|Link
|Link
|Ethernet, Wifi
|802.1X, WPA
|-
|Physical
|
|
|
|}


=== TLS protocol ===
PRF_HMAC_SHA2_384
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
PRF_HMAC_SHA2_512
• TLS version to use
• Verify hashing of public/private key (X.509 certificate)
• Asymmetric key
• Exchange symmetric session keys
• Negotiate stream/block cipher to encrypt the payload.
• Choose random Initialization Vector
TLS used by default MAC-then-encrypt. The message padding can lead to attacks, which can be mitigated by authenticated encryption like AES-GCM.
Cryptography suites involve multiple steps and for each step different algorithms can be chosen. For instance, RSA describes multiple standards (PKCS). PKCS#1 describes both public/private asymmetrical keys and encoding/padding schemes for encryption/decryption and verifying of signatures. It’s possible to use RSA for some steps and other algorithms for the other steps.
In a TLS message there are 3 places where a version is set. For backwards compatibility
In the record layer the minimum version is set (here 0x0301 for TLS 1.0). In the ClientHello the version 0x0304 for TLS 1.2 originally was the highest supported version. 1.2 supports extensions. Since TLS 1.3 the extension “supported version” contains a list of versions that are supported.


=== TLS Handshake ===
Diffie-Hellman Group Curve25519 (group 31)
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 
256-bit random ECP group (group 19)


=== HTTPS ===
384-bit random ECP group (group 20)
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'''
Authentication method Digital Signature (method 14) with ECDSA or RSASSA-PSS


https://wiki.archlinux.org/title/HTTP_tunneling#Using_corscrew_and_HTTP_CONNECT
=== ESP Recommended Algorithms ===
Encryption ENCR_AES_GCM_16


=== SSH ===
ENCR_CHACHA20_POLY1305
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
Authentication AUTH_HMAC_SHA2_256_128


=== IPsec ===
AUTH_AES_128_GMAC
[[File:IPsec IKE.png|thumb]]
AUTH_AES_256_GMAC
[[File:Ipsec-ike2.png|thumb]]
IPsec originates as header for IPv6 and has been ported as protocol on IPv4.


RFC 4301
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.
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.
Other relevant source of information NIST 800-77 Rev. 1 (Draft), BSI TR-02102-3 and ANSSI DAT-NT-003-EN.
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)
The Core Infrastructure Initiative (CII)  (by the Linux Foundation) organizes "The Best Practices Badge" program, which is an open source secure development maturity model.


Phase I, Negotiate Setting, e.g. with IKE
More information and the complete list of the criteria can be found in the Badge Program github repository.


Phase II, Establish connection.
https://www.coreinfrastructure.org/


https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
https://www.coreinfrastructure.org/programs/badge-program


=== IKEv1 ===
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
Initial Key Exchange


RFC 2409 obsoleted by IKEv2
=== 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


Oakley protocol and ISAKMP.
OpenSC is the SoftHSM, their pkcs11-tool can be used 


=== IKEv2 ===
http://wiki.ncryptoki.com/MainPage.ashx
RFC 7296


  IKEv2 adds EAP authentication
  apt install softhsm2 opensc
  IKEv2 adds MOBIKE
  softhsm2-util --init-token --slot 0 --label "softhsm"
  IKEv2 adds NAT traversal
   
  IKEv2 adds tunnel alive detection
  ls -la /var/lib/softhsm/tokens/
  IKE key exchange
   
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'


  SPD Security Policy
  alias pkcs11-tool='/usr/bin/pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so'
  SAD Security Association.
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


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


=== TLS Origins ===
importing a private key
[[File:TLS History.png|thumb|TLS History]]
ITU-T and ISO defined networking protocols in the ‘80s and ‘90s. Today the visible remains are the OSI model, the IS-IS protocol used between IP routers, SNMP, LDAP and the PKIX infrastructure with the X.509 certificates adopted by IETF as RFC 5280. Certificates were standardized as part of the OSI protocols, which where directly competing with IETF TCP/IP during the protocol wars.


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


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/
exporting public key


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.
pkcs11-tool -l -p ${p11pin} --list-objects
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type pubkey -o csf0.der


=== SSL vs TLS ===
pkcs11-tool -l -p ${p11pin} --id ${keyid} --read-object --type privkey -o private_key.pem
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.
=== OpenSSL ===
https://wiki.openssl.org/index.php/OpenSSL_3.0


All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
openssl genrsa -out private-key.pem 4096
{| class="wikitable"
openssl rsa -in private-key.pem -text -noout
|+
openssl asn1parse -in private-key.pem
!Version
openssl rsa -in private-key.pem -pubout -out public-key.pem
!By
openssl asn1parse -in public-key.pem
!Date
openssl rsa -pubin -inform pem -in public-key.pem -outform der -out public-key.der
!Security
 
!
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
|SSLv1
openssl base64 -in testsign.sha256 -out signature
|Netscape
openssl base64 -d -in signature -out testsign.sha256
|1994
openssl dgst -sha256 -verify public-key.pem -signature testsign.sha256 ranger_1.8.1-0.2_all.deb
|Never released
 
|
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
|SSLv2
openssl pkeyutl -verifyrecover -in sig -inkey private-key.pem
|Netscape
openssl pkeyutl -verify -in file -sigfile sig -inkey private-key.pem
|1995
 
|Vulnerable
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
|-
 
|SSLv3
openssl x509 -noout -modulus -in public.crt | openssl sha256
|Netscape
openssl rsa -noout -modulus -in private-key.pem | openssl sha256
|1996
cat public-key.pem | base64 -d | openssl asn1parse -inform DER -i -strparse 19
|Vulnerable
 
|
https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm
|-
 
|TLSv1.0
== TLS Transport Layer Security ==
|[rfc:2246 IETF RFC 2246]
 
|1999
=== TLS Origins ===
|Header Compression is broken
[[File:TLS History.png|thumb|TLS History]]
|may be needed for older clients like Java 6, Windows 7/Server 2008, IE 8 or Android 4
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.
|-
 
|TLSv1.1
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/.
|[rfc:4346 IETF RFC 4346]
 
|2006
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/
|Quickly replaced by TLSv1.2
 
|
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.
|-
|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/
=== 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.


https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
SSL was standardized by Netscape based on ITU-T X.500 and RSA PKCS standards. TLS is the successor specified under IETF.


=== TLS Certificate Profiles ===
All SSL versions are deprecated and broken. Do not use SSLv2 or SSLv3. Attacks on TLS involve clients to downgrade to SSL.
Netscape developed SSL by adopting X.500. In 1999 when IETF continued the protocal as TLS it has created profiles to use X.509 certificates for instance for Webservers and Email.  
{| class="wikitable"
{| class="wikitable"
|+
|+
!Version
!Version
!Specification
!By
!Date
!Date
!Security
!Security
!
|-
|-
|X.509v1
|SSLv1
|T-REC-X.509/en
|Netscape
|July 1988
|1994
|Never released
|
|
|-
|-
|X.509v2
|SSLv2
|
|Netscape
|1993
|1995
|Vulnerable
|
|
|-
|-
|X.509v3
|SSLv3
|Netscape
|1996
|Vulnerable
|
|
|June 1996
|Additional extension fields
|-
|-
|IETF PKI
|TLSv1.0
|RFC2459
|[rfc:2246 IETF RFC 2246]
|January 1999
|1999
|Profiles for applicability
|Header Compression is broken
|may be needed for older clients like Java 6, Windows 7/Server 2008, IE 8 or Android 4
|-
|-
|IETF PKI
|TLSv1.1
|RFC3280
|[rfc:4346 IETF RFC 4346]
|April 2002
|2006
|Quickly replaced by TLSv1.2
|
|-
|TLSv1.2
|[rfc:5246 IETF RFC 5246]
|2008
|Good enough
|
|
|-
|-
|IETF PKI
|TLSv1.3
|RFC5280
|IETF RFC8446
|May 2008
|2018
|
|
|Introduces features like 0-RTT, removes legacy ciphers
|}
|}
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.
https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols


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
https://tls13.xargs.org/
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'.
https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html


There are several file formats for encoding certificates. The binary format can be one of the PKCS based p7b, p12 or pxf (RFC 7292) or in the ASN.1 DER format. DER can be encapsulated in Base64 as PEM (Privacy Enhanced Mail RFC 7468) and put between begin and end labels
=== TLS protocol ===
  -----BEGIN <LABEL>-----
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.
<base64>
The most important values negotiated are
-----END <LABEL>-----
• 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.


  -----BEGIN CERTIFICATE-----
=== TLS Certificate Profiles ===
  MII…==
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.
  -----END CERTIFICATE-----
{| class="wikitable"
 
|+
  LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t
!Version
 
!Specification
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
!Date
 
!Security
=== TLS Termination ===
|-
 
|X.509v1
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.
|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.
 
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.
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.
Line 1,051: Line 1,105:
cat /proc/sys/kernel/random/entropy_avail
cat /proc/sys/kernel/random/entropy_avail


=== File format ===
=== TLS Handshake ===
DER is an ASN.1 file format. PEM is a DER in Base 64.
After the initial TCP handshake (3 way SYN - SYN/ACK – ACK). TLS uses a 4-way handshake (ClientHello - ServerHello - ServerKey – ClientKey).
Keys can be


1. DER ASN.1
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.


2. SSLeay format (used by OpenSSL)
TLS 1.3 can use 0-RTT to reduce the roundtrips and the version is negotiated as a list.


3. PKCS#8 / RFC5208
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.


4. PKCS#7 as supported by Java Keytool
[] Indicates messages protected using keys derived from traffic_secret_N
https://blog.cloudflare.com/introducing-tls-1-3/


5. PKCS#12 PFX or P12, certificate chain, used commonly by Microsoft and as method to import private keys into a Java Keystore
TCP Fast Open, TLS False Start


=== SAN ===
=== HTTPS ===
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
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.
https://wiki.cacert.org/FAQ/subjectAltName


=== Certificate Authority ===
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.
ROOT CA


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


* Server Cert WG
A full URL should contain the schema defines if TLS should be negotiated first.
* Code Signing Cert WG
* S/MIME Cert WG
* Net-Sec WG


=== Certificate Transparency ===
schema://domainname:[port]/
https://crt.sh/?q=janmg.com


https://certificate.transparency.dev/howctworks/
https://domain.name.com:443/


https://datatracker.ietf.org/doc/html/rfc6962
'''Tunnel Socks over TLS'''


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.
https://wiki.archlinux.org/title/HTTP_tunneling#Using_corscrew_and_HTTP_CONNECT


=== TPM 2.0 ===
=== ROOT CA ===
Attestation
Root program, truststore


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


Secure Device Identity
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.


https://1.ieee802.org/security/802-1ar/
The IP address from Comodo is in the range of 91.199.212.0/24.


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


=== BRSKI ===
certbot certonly --standalone --email ${MAIL} --agree-tos -d ${DOMAIN}
Vendor certificates


ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)
cd /etc/letsencrypt/live/


Autonomic Control Plane
cat privkey.pem fullchain.pem > combined.pem


https://datatracker.ietf.org/doc/html/rfc8995
X3 Root


=== self signed certificate ===
https://www.identrust.com/support/downloads
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
Convert from DER to PEM and then from P7B to Cert


openssl genrsa -aes256 -out ca.key 4096
openssl x509 -inform der -in trustidrootx3_chain.p7b -out root.p7b


openssl req -subj '/CN=JANMG_ROOT_CA' -new -x509 -days 3652 -key ca.key -out ca.crt
openssl pkcs7 -print_certs -in root.p7b -out root.pem


https://letsencrypt.org/certificates/


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
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 req -subj '/CN=hostname' -new -key host.key -out host.csr
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
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -CAkey ca.key -out host.crt
Line 1,147: Line 1,250:
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -set_serial "0x$(openssl rand -hex 16)" -CAkey ca.key -out host.crt
openssl x509 -req -days 1828 -in host.csr -CA ca.crt -set_serial "0x$(openssl rand -hex 16)" -CAkey ca.key -out host.crt


=== Docker ===
== Local Certificates ==
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
Browsers follow CA/Browser and therefor local webservers can not have certificates relevant in the local scope.


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


/etc/sysconfig/docker
https://cabforum.org/uploads/CA-Browser-Forum-BR-v2.0.1.pdf


--insecure-registry myregistrydomain.com:5000
7.1.2.7.12 Subscriber Certificate Subject Alternative Name


boot2docker
https://iotsecurityfoundation.org/router-and-iot-device-vulnerabilities-solutions-to-a-design-flaw/  
echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile


=== Namecheap ===
https://specs.manysecured.net/suib/
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.
# Address of the local device
# Browser
# Certificate trust


The IP address from Comodo is in the range of 91.199.212.0/24.
==== MDNS ====
mdns-scan


=== Letsencrypt ===
Resolve-DnsName philips-hue.local
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.
dig -p 5353 philips-hue.local @224.0.0.251


certbot certonly --standalone --email ${MAIL} --agree-tos -d ${DOMAIN}
https://www.gabriel.urdhr.fr/2019/04/02/llmnr-mdns-cli-lookup/


cd /etc/letsencrypt/live/
apk add avahi
service avahi-daemon start
avahi-browse -a


cat privkey.pem fullchain.pem > combined.pem
=== 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


X3 Root
-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/ssl/certs/docker-registry -e REGISTRY_HTTP_TLS_KEY=/etc/ssl/private/docker-registry


https://www.identrust.com/support/downloads
/etc/sysconfig/docker


Convert from DER to PEM and then from P7B to Cert
--insecure-registry myregistrydomain.com:5000


openssl x509 -inform der -in trustidrootx3_chain.p7b -out root.p7b
boot2docker
echo 'EXTRA_ARGS="--insecure-registry docker.janmg.com:5000"'| sudo tee -a /var/lib/boot2docker/profile


openssl pkcs7 -print_certs -in root.p7b -out root.pem
== Other encrypting protocols ==


https://letsencrypt.org/certificates/
=== 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 ===
[[File:IPsec IKE.png|thumb]]
[[File:Ipsec-ike2.png|thumb]]
IPsec originates as header for IPv6 and has been ported as protocol on IPv4.


   
RFC 4301
docker volume create letsencrypt
  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.
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
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.
server {
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.
            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;


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)


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
Phase I, Negotiate Setting, e.g. with IKE
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.
Phase II, Establish connection.


=== Browsers ===
https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
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/
=== IKEv1 ===
Initial Key Exchange


Owner Root Store
RFC 2409 obsoleted by IKEv2


Adobe www.adobe.com/security/approved-trust-list.htm
Oakley protocol and ISAKMP.


Mozilla Overview of All CA-Related Mozilla Documentation
=== IKEv2 ===
RFC 7296


Mozilla Root Certificate Program
IKEv2 adds EAP authentication
IKEv2 adds MOBIKE
IKEv2 adds NAT traversal
IKEv2 adds tunnel alive detection
IKE key exchange


Microsoft aka.ms/RootCert
SPD Security Policy
SAD Security Association.


Microsoft Root Certificate Program
== Certificates ==


Google dev.chromium.org/Home/chromium-security/root-ca-policy
=== File format ===
DER is an ASN.1 file format. PEM is a DER in Base 64 with ascii armor


Apple www.apple.com/certificateauthority/ca_program.html
1. DER ASN.1


Oracle www.oracle.com/technetwork/java/javase/javasecarootcertsprogram-1876540.html
2. SSLeay format (used by OpenSSL)


Linux includes the Mozilla NSS services which comes with a Root CA’s usually installed in /etc/ssl
3. PKCS#8 / RFC5208
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.
4. PKCS#7 as supported by Java Keytool


• Android 4.4.2
5. PKCS#12 PFX or P12, certificate chain, used commonly by Microsoft and as method to import private keys into a Java Keystore


• Firefox 32
=== 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


• IE 11
https://wiki.cacert.org/FAQ/subjectAltName


• IE Mobile 11
=== Certificate Authority ===
ROOT CA


• Java 8
https://cabforum.org/


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


'''TLS 1.3 Support'''
=== Certificate Transparency ===
https://crt.sh/?q=janmg.com
 
https://certificate.transparency.dev/howctworks/


TLS 1.3 was in state AUTH48*R with the last author review being done before release
https://datatracker.ietf.org/doc/html/rfc6962
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
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.
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'''
=== TPM 2.0 ===
Attestation


https://wiki.wireshark.org/TLS
=== IEEE 802.1AR ===


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.
Secure Device Identity


https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/
https://1.ieee802.org/security/802-1ar/


Firefox needs NSS_ALLOW_SSLKEYLOGFILE=1 explicitly set during compilation or use the Firefox Developer edition.
IDevID
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format


=== Windows ===
=== BRSKI ===
Schannel. Windows secure channel is the subsystem that deals with encryption
Vendor certificates
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
ANIMA Bootstrapping Remote Secure Key Infrastructure (BRSKI)


UseStrongCrypto
Autonomic Control Plane


=== Linux ===
https://datatracker.ietf.org/doc/html/rfc8995
Linux kernel supports TPM and SHA/AES


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


=== Redhat Enterprise Linux ===
https://cabforum.org/browser-os-info/
Redhat is using the NSS utils for certificate management
{| class="wikitable"
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
|+
yum install ca-certificates
!Owner
 
!Root Store
cd /etc/pki/ca-trust/source/anchors/
!Link
 
!
update-ca-trust extract
|-
|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


/etc/pki/tls/certs/
http://hg.mozilla.org/releases/mozilla-release/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert


vi /etc/openldap/ldap.conf
The Chrome Browser uses the platform specific truststore. ChromeOS uses it’s own Chromium Root CA.


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


=== Alpine Linux ===
'''TLS 1.2 Support'''
apk add ca-certificates


/usr/local/share/ca-certificates/
The versions of clients that can initiate TLSv1.2 connections should be at least.


update-ca-certificates
• Android 4.4.2


/etc/ssl/certs/
• Firefox 32


/usr/bin/c_rehash /etc/ssl/certs
• IE 11


WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
• IE Mobile 11
 
• Java 8
 
• Safari 7


rm -rf /etc/ssl/certs/ca-certificates.crt
'''TLS 1.3 Support'''


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


cURL
rfc:8446


wget
Firefox 63 and Chrome 70 in October 2018 will support TLS 1.3 as 0x0304. Older versions support Draft 28 as 0x7F1C.


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


OpenSSH
https://hg.mozilla.org/mozilla-central/


Apache Traffic Manager
OpenSSL version 1.1.1 from September 2018 supports TLSv1.3


OpenConnect
include/openssl/tls1.h


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


== Implementations ==
'''Wireshark'''


=== JAVA ===
https://wiki.wireshark.org/TLS
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 ===
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.
Convert between formats


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


keytool -keystore janmg.jks -list
Firefox needs NSS_ALLOW_SSLKEYLOGFILE=1 explicitly set during compilation or use the Firefox Developer edition.


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


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


keytool -printcert -v -file janmg.p7b
.NET Framework versions prior to 4.7


keytool -list -v -keystore janmg.jks -alias janmg1
UseStrongCrypto


openssl x509 -text -inform DER -in janmg.p7b
=== Linux ===
Linux kernel supports TPM and SHA/AES


'''PEM'''
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto


openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt
=== Redhat Enterprise Linux ===
Redhat is using the NSS utils for certificate management
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html


openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt
yum install ca-certificates


openssl x509 -text -inform PEM -in janmg.crt
cd /etc/pki/ca-trust/source/anchors/


'''DER / XER'''
update-ca-trust extract


...
/etc/pki/tls/certs/


'''P12'''
certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert


openssl pkcs12 -in janmg.p12 -nodes -legacy
vi /etc/openldap/ldap.conf


'''Keystore to P12'''
TLS_REQCERT never


keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
=== Alpine Linux ===
apk add ca-certificates


openssl pkcs12 -info -in janmg.p12
/usr/local/share/ca-certificates/


openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key
update-ca-certificates


'''VERIFY MATCH'''
/etc/ssl/certs/


openssl x509 -noout -modulus -in juststar.crt | openssl md5
/usr/bin/c_rehash /etc/ssl/certs
openssl rsa -noout -modulus -in janmg.key | openssl md5


'''P12 to Keystore'''
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping


openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12
rm -rf /etc/ssl/certs/ca-certificates.crt
keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12


'''Merge private key and chain'''
update-ca-certificates


cat privkey.pem fullchain.pem > combined.pem


'''JRUBY'''


jruby-openssl
cURL
https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol


GO crypto/tls
wget


NGINX
Qt


OpenSSH


=== HAPROXY ===
Apache Traffic Manager
/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
OpenConnect
    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
TianoCore/EDKII
    bind :::80 v4v6 tfo
    mode http
    redirect scheme https code 301 if !{ ssl_fc }


frontend https-in
== Implementations ==
    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"
=== Java Keystore / Truststore ===
    http-response set-header X-Content-Type-Options "nosniff"
Convert between formats
    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 ===
'''KEYTOOL'''
LDAPS


cat root.pem chain.pem > root-intermediate.pem
keytool -keystore janmg.jks -list
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem


dn: cn=config
'''P7B'''
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/cert.pem


dn: cn=config
keytool -keystore janmg.jks -exportcert -alias janmg1 > janmg.p7b
changetype: modify
 
replace: olcTLSCertificateKeyFile
keytool -printcert -v -file janmg.p7b
olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem


ldapmodify -Y EXTERNAL  -H ldapi:/// -f certs.ldif
keytool -list -v -keystore janmg.jks -alias janmg1


=== SSL Libraries ===
openssl x509 -text -inform DER -in janmg.p7b
https://www.feistyduck.com/library/openssl%2dcookbook/


1995 SSLeay (by Eric A. Young and Tim J. Hudson)
'''PEM'''
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.
openssl pkcs7 -inform der -in janmg.p7b -out janmg.crt


https://hg.mozilla.org/projects/nss
openssl pkcs7 -print_certs -in janmg.p7b -out janmg.crt


=== OpenSSL ===
openssl x509 -text -inform PEM -in janmg.crt
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.


https://www.openssl.org/source/
'''DER / XER'''


https://endoflife.date/openssl
...
{| class="wikitable"
 
|+OpenSSL
'''P12'''
!version
 
!support
openssl pkcs12 -in janmg.p12 -nodes -legacy
!introduced
 
!last version
'''Keystore to P12'''
!redhat
 
|-
keytool -importkeystore -srckeystore janmg.jks -destkeystore janmg.p12 -deststoretype PKCS12 -srcalias janmg1
|0.9.8
 
|eol
openssl pkcs12 -info -in janmg.p12
|Jul 2005
 
|0.9.7m (February 23, 2007)
openssl pkcs12 -in janmg.p12 -nodes -nocerts -out janmg.key
|
 
|-
'''VERIFY MATCH'''
|1.0.0
 
|eol
openssl x509 -noout -modulus -in juststar.crt | openssl md5
|Mar 2010
openssl rsa -noout -modulus -in janmg.key | openssl md5
|1.0.0t (December 3, 2015)
 
|
'''P12 to Keystore'''
|-
 
|1.0.1
openssl pkcs12 -export -in star.crt -inkey janmg.key -name "janmg1" -out janmg.p12
|eol
keytool -importkeystore -destkeystore janmg.jks -srckeystore janmg.p12 -srcstoretype PKCS12
|Mar 2012
 
|1.0.1u (Sep 22, 2016)
'''Merge private key and chain'''
|1.0.1e-51.el7_2
 
|-
cat privkey.pem fullchain.pem > combined.pem
|1.0.2
 
|eol
'''JRUBY'''
|Jan 2015
 
|1.0.2n (Dec 7, 2017)
jruby-openssl
|
https://github.com/net-ssh/net-sftp/tree/master/lib/net/sftp/protocol
|-
 
|1.1.0
GO crypto/tls
|eol
 
|Aug 2016
NGINX
|
 
|
 
|-
=== HAPROXY ===
|1.1.1w
/etc/haproxy/haproxy.cfg
|eol
    tune.ssl.default-dh-param 2048
|May 2018
    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
|First version to support TLS 1.3
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
|el8 1.1.1k
 
|-
    ssl-server-verify none
|3.0
    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
|lts
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
|Sep 2021
 
|Redesign with providers instead of engines
frontend http-in
|
    bind :::80 v4v6 tfo
|-
    mode http
|3.1
    redirect scheme https code 301 if !{ ssl_fc }
|
|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
frontend https-in
 
    bind :::443 v4v6 tfo ssl crt /etc/letsencrypt/live/janmg.com/combined.pem alpn http/1.1,http/1.0
https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
    http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 
    http-response set-header X-Content-Type-Options "nosniff"
wget https://www.openssl.org/source/openssl-3.0.8.tar.gz
    http-response set-header X-Frame-Options "DENY"
tar xvzf openssl-3.0.8.tar.gz
    http-response set-header X-XSS-Protection "1; mode=block"
cd openssl-3.0.8/
    http-response set-header Referrer-Policy "strict-origin"
perl Configure
    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'"
perl configdata.pm --dump
    default_backend app
perl Configure no-deprecated no-ssl no-des
backend app
perl configdata.pm --dump
    balance source
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
    http-request add-header X-Forwarded-Proto https


https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/openssl/openssl-3.1.5-r5.log
=== OPENLDAP ===
LDAPS


Ubuntu
cat root.pem chain.pem > root-intermediate.pem
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/root-intermediate.pem


https://launchpadlibrarian.net/731303906/buildlog_ubuntu-oracular-amd64.openssl_3.0.13-0ubuntu4_BUILDING.txt.gz
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/cert.pem


  ./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
  dn: cn=config
make
changetype: modify
sudo make install
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/


Configuration options don't seem to matter much for OpenSSL 3.0
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


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.
Mozilla maintains the NSS (Network Security Services) project that implements TLS and S/MIME for clients like Firefox.


=== Unattended CSR ===
https://hg.mozilla.org/projects/nss


[req]
=== OpenSSL ===
prompt = no
OpenSSL is a toolkit with a command line application and libraries for SSL and one for Crypto functions.
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://www.openssl.org/source/


openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr
https://endoflife.date/openssl
 
{| class="wikitable"
=== OpenSSL Commands ===
|+OpenSSL
openssl version
!version
 
!support
openssl version -d
!introduced
 
!last version
Show Certificate content
!redhat
 
|-
openssl s_client -connect www.islief.com:443
|0.9.8
 
|eol
CTRL-D
|Jul 2005
 
|0.9.7m (February 23, 2007)
Test HTTP
|
 
|-
openssl s_client -connect aws.islief.com:443
|1.0.0
 
|eol
HEAD / HTTP/1.0
|Mar 2010
 
|1.0.0t (December 3, 2015)
Host: aws.islief.com
|
 
|-
(After the HTTP Headers use an empty line)
|1.0.1
 
|eol
Downloading Certificates
|Mar 2012
 
|1.0.1u (Sep 22, 2016)
echo | openssl s_client -connect aws.islief.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > download.crt
|1.0.1e-51.el7_2
 
|-
Print Certificate Values
|1.0.2
 
|eol
openssl x509 -in download.crt -noout -text
|Jan 2015
 
|1.0.2n (Dec 7, 2017)
openssl x509 -in download.crt -noout -subject -issuer -startdate -enddate
|
 
|-
Print Certificate Issuer and Subject
|1.1.0
 
|eol
for CERT in $(ls -1 *.crt) ;do echo ${CERT};openssl x509 -in ${CERT} -noout -text -issuer -subject;done
|Aug 2016
 
|
https://www.sslshopper.com/certificate-decoder.html
|
 
|-
openssl x509 -in certificate.crt -text -noout
|1.1.1w
 
|eol
openssl verify -CAfile root.crt node.crt
|May 2018
 
|First version to support TLS 1.3
openssl x509 -in node.crt -fingerprint -sha256
|el8 1.1.1k
 
|-
Do private key and certificate match
|3.0
openssl rsa -in [privatekey] -check
|lts
 
|Sep 2021
openssl pkey -in [privatekey] -pubout -outform der | sha256sum
|Redesign with providers instead of engines
openssl x509 -in [certificate] -pubkey |openssl pkey -pubin -pubout -outform der | sha256sum
|
 
|-
=== GNUTLS ===
|3.1
gnutls-cli
|
 
|Mar 2023
gnutls-serv
|
 
|
certtool
|-
 
|3.2
ocsptool
|
 
|Nov 2023
srptool
|
|
|-
|3.3
|
|Apr 2024
|
|
|}
https://wiki.openssl.org/index.php/TLS1.3


p11tool
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


gnutls-cli-debug
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


psktool
Ubuntu


=== TLS Validation ===
https://launchpadlibrarian.net/731303906/buildlog_ubuntu-oracular-amd64.openssl_3.0.13-0ubuntu4_BUILDING.txt.gz
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/
./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
https://testssl.sh/openssl-rfc.mappping.html
make
sudo make install


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


https://github.com/nabla-c0d3/sslyze
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.


Mozilla Configuration
=== Unattended CSR ===


Mozilla has a Server Configuration Generator for webservers like Apache and NGINX with recommended SSL Configurations.
[req]
https://wiki.mozilla.org/Security/Server_Side_TLS
prompt = no
   
distinguished_name = dn
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. 
req_extensions = ext
== HTTP Webserver Security ==
input_password = PASSPHRASE
Mozilla Observatory
  [dn]
Mozilla has an observatory with TLS or HTTP headers to scan for common security configuration omissions.
CN = www.feistyduck.com
https://observatory.mozilla.org
emailAddress = webmaster@feistyduck.com
O = Feisty Duck Ltd
L = London
C = GB
[ext]
subjectAltName = DNS:www.mydomain.com,DNS:mydomain.com


HTTP Headers
openssl req -new -config fd.cnf -key fd.key -out fd.csr
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
openssl req -subj '/CN=janmg.com/O=janmg/emailAddress=admin@janmg.com/' -new -key host.key -out host.csr
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
=== OpenSSL Commands ===
Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.


Content-Security-Policy
openssl version
openssl version -d
 
Show Certificate content


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.
openssl s_client -connect www.islief.com:443
CTRL-D


X-Frame-Options
Test HTTP
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
openssl s_client -connect aws.islief.com:443
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.
HEAD / HTTP/1.0
Host: aws.islief.com


Public-Key-Pins
(After the HTTP Headers use an empty line)
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
Downloading Certificates
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
echo | openssl s_client -connect aws.islief.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > download.crt
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 ===
Print Certificate Values
HTTPOnly


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


=== NGINX HTTP Headers ===
Print Certificate Issuer and Subject
server_tokens off;
 
add_header X-Frame-Options SAMEORIGIN;
for CERT in $(ls -1 *.crt) ;do echo ${CERT};openssl x509 -in ${CERT} -noout -text -issuer -subject;done
add_header X-Content-Type-Options nosniff;
 
add_header X-XSS-Protection "1; mode=block";
https://www.sslshopper.com/certificate-decoder.html
add_header 'Access-Control-Allow-Origin' '*';
 
add_header 'Access-Control-Allow-Methods' 'GET, POST';
openssl x509 -in certificate.crt -text -noout
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
openssl verify -CAfile root.crt node.crt
add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
openssl x509 -in node.crt -fingerprint -sha256


=== HAPROXY HTTP Headers ===
Do private key and certificate match
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 ==
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


=== DANE ===
Engines
_443._tcp IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
  openssl info -enginesdir
https://check.sidnlabs.nl/dane/
13.2 CAA
@        IN CAA          0 issue "letsencrypt.org"


=== DNSSEC ===
=== GNUTLS ===
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
gnutls-cli
/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 ==
gnutls-serv


==== GSM ====
certtool
A5/1 A5/2 A5/3 A5/4


DES AES
ocsptool


GPRS
srptool


UMTS
p11tool


LTE
gnutls-cli-debug


==== Tetra ====
psktool
TEA1 ... TEA7


https://www.cryptomuseum.com/crypto/algo/tea/1.htm
=== 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


== Attacks ==
https://testssl.sh/
https://testssl.sh/openssl-rfc.mappping.html
 
SSLYZE


Man in the Middle
https://github.com/nabla-c0d3/sslyze
sslstrip or mitmproxy


Security Issues and Attacks
Mozilla Configuration
https://tools.ietf.org/html/rfc7457
downgrade attack (TLS_FALLBACK_SCSV)


FREAK
Mozilla has a Server Configuration Generator for webservers like Apache and NGINX with recommended SSL Configurations.
Side-channel attacks
https://wiki.mozilla.org/Security/Server_Side_TLS
ECC / Weil_restriction
https://www.owasp.org/images/d/d8/OWASP_SSL_20131128_preso.pdf
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


Year Name Attack Against CVE
HTTP Headers
2001 Fluhrer, Mantin and Shamir RC4
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
2002 Padding Oracle Padding Oracle
Content-Security-Policy
2004 Dual_EC_DRBG Backdoor Random Generator
X-Frame-Options X-XSS-Protection:1; mode=block
2009 Renegotiation CVE-2009-3555
https://wiki.mozilla.org/Security/Guidelines/Web_Security
2011 StartSSL Command Injection CVE-2014-0411
https://securityheaders.io/?q=janmg.com&hide=on&followRedirects=on
2011 Beast IV CVE-2011-3389
 
2012 Flame
Strict-Transport-Security
Time Compression
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.
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 ===
X-Content-Type-Options
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.
Can be set to nosniff if we are absolutely sure we advertise all mime-types correctly.
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
Content-Security-Policy
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.
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.


https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology
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.


{| class="wikitable" style="font-size:85%;"
Content-Security-Policy
|-
https://content-security-policy.com/
! Date
add_header Content-Security-Policy "default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self'; connect-src 'self'; img-src 'self'; ";
! Year
 
! Event
==== CORS Cross Origin. ====
|-
When some resources come from other domains.
| 15 May
 
| 1973
XMLHttpRequest
| NBS publishes a first request for a standard encryption algorithm
 
|-
Access-Control-Allow-Origin
| 27 August
 
| 1974
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
| NBS publishes a second request for encryption algorithms
 
|-
http://enable-cors.org/
| 17 March
 
| 1975
Preflight request using HTTP Method OPTIONS
| DES is published in the ''Federal Register'' for comment
 
|-
12.5 Sub Resource Integrity
| August
 
| 1976
https://www.w3.org/TR/SRI/
| First workshop on DES
 
|-
With subresource integrity, additional resources like CSS or JS can only load when the integrity hashes are included in the HTML page.
| September
 
| 1976
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
| Second workshop, discussing mathematical foundation of DES
 
|-
<script type="text/javascript" src="/js/script.js" integrity="sha512-5h4b3yOdQ+…3cOoj9kw=="></script>
| November
 
| 1976
curl -s https://website/js/script.js | openssl dgst -sha512 -binary | openssl base64 -A
| DES is approved as a standard
 
|-
=== Cookies ===
| 15 January
HTTPOnly
| 1977
 
| DES is published as a FIPS standard FIPS PUB 46
Secure
|-
 
| June
=== NGINX HTTP Headers ===
| 1977
server_tokens off;
| [[Whitfield Diffie|Diffie]] and [[Martin Hellman|Hellman]] argue that the DES cipher can be broken by brute force.<ref name="dh-exh"/>
add_header X-Frame-Options SAMEORIGIN;
|-
add_header X-Content-Type-Options nosniff;
|
add_header X-XSS-Protection "1; mode=block";
| 1983
add_header 'Access-Control-Allow-Origin' '*';
| DES is reaffirmed for the first time
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";
| 1986
 
| [[Videocipher]] II, a TV satellite scrambling system based upon DES, begins use by HBO
=== HAPROXY HTTP Headers ===
|-
http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
| 22 January
http-response set-header X-Content-Type-Options "nosniff"
| 1988
http-response set-header X-Frame-Options "DENY"
| DES is reaffirmed for the second time as FIPS 46-1, superseding FIPS PUB 46
http-response set-header X-XSS-Protection "1; mode=block"
|-
http-response set-header Referrer-Policy "strict-origin"
| July
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'"
| 1991
 
| Biham and Shamir rediscover [[differential cryptanalysis]], and apply it to a 15-round DES-like cryptosystem.
 
|-
== DNS ==
|
 
| 1992
=== DANE ===
| 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.
_443._tcp IN TLSA  2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
|-
 
| 30 December
https://check.sidnlabs.nl/dane/
| 1993
 
| DES is reaffirmed for the third time as FIPS 46-2
13.2 CAA
|-
 
|
@        IN CAA          0 issue "letsencrypt.org"
| 1994
 
| The first experimental cryptanalysis of DES is performed using linear cryptanalysis (Matsui, 1994).
=== DNSSEC ===
|-
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
| June
 
| 1997
/etc/bind/zone/janmg.com
| The [[DESCHALL Project]] breaks a message encrypted with DES for the first time in public.
 
|-
cd /var/bind/
| July
 
| 1998
dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE janmg.com
| The [[Electronic Frontier Foundation|EFF]]'s [[EFF DES cracker|DES cracker]] (Deep Crack) breaks a DES key in 56 hours.
 
|-
dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE janmg.com
| January
 
| 1999
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
| Together, [[Deep Crack]] and [[distributed.net]] break a DES key in 22 hours and 15 minutes.
service named restart
|-
dnssec-dsfromkey -2 -f janmg.com.signed janmg.com
| 25 October
 
| 1999
dig A janmg.com. @localhost +noadditional +dnssec +multiline
| 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.
 
|-
dig +dnssec +short @localhost janmg.com
| 26 November
 
| 2001
https://dnssec-debugger.verisignlabs.com/janmg.com
| The [[Advanced Encryption Standard]] is published in FIPS 197
 
|-
=== Additional Topics ===
| 26 May
Where is crypto
| 2002
 
| The AES becomes effective
Asics delid, netlist
|-
| 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 ===
Fpga bitstream
StuxNet, Duqu


Comodo (2011)
Hawkeye


DigiNotar (2011)
Aes slideshow


Turktrust (2012)
Fpga opentitan
=== Passwords ===


Algorithms
Son, arx, feistel


https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm
Caliptra


https://password-hashing.net/
Joe Grant


Argon2, Bcrypt and Pbkdf2
Blackberry


PBKDF2 RSA RFC 8018
== Telecom ==


BCrypt Blowfish
==== GSM ====
A5/1 A5/2 A5/3 A5/4


SCrypt
DES AES


GPRS


UMTS


Linux Passwords
LTE
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 ===
==== Tetra ====
/etc/pam.d/common-password
TEA1 ... TEA7


=== HTTP Authorization Header ===
https://www.cryptomuseum.com/crypto/algo/tea/1.htm
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
== Attacks ==
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
Man in the Middle
sslstrip or mitmproxy


=== JWT ===
Security Issues and Attacks
<nowiki>https://jwt.io</nowiki>
https://tools.ietf.org/html/rfc7457
downgrade attack (TLS_FALLBACK_SCSV)


RFC 7520 JOSE JSON Object Signing and Encryption
FREAK
Side-channel attacks
ECC / Weil_restriction
https://www.owasp.org/images/d/d8/OWASP_SSL_20131128_preso.pdf


JSON Web Signature (JWS)
Year Name Attack Against CVE
 
2001 Fluhrer, Mantin and Shamir RC4
JSON Web Encryption (JWE)
2002 Padding Oracle Padding Oracle
 
2004 Dual_EC_DRBG Backdoor Random Generator
JSON Web Key (JWK)
2009 Renegotiation CVE-2009-3555
 
2011 StartSSL Command Injection CVE-2014-0411
JSON Web Algorithm (JWA)
2011 Beast IV CVE-2011-3389
 
2012 Flame
JSON Web Token (JWT)
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


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


Authlib, jose, pyjwt, python-jose, JWCrypto
Crime, Breach, Heist: decrypt payloads by manipulating the file compression


=== Secure Storage and Functions ===
=== Life span of a cipher ===
TPM, HSM, Secure Elements, OP-TEE
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.


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


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


IV Initialization Vector
https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology


Padding
{| class="wikitable" style="font-size:85%;"
 
|-
=== Others ===
! Date
Key negotiation DH Ecliptic Curve / Prime pairs
! Year
 
! Event
Curve Issues
|-
 
| 15 May
Export Grade DHE
| 1973
 
| NBS publishes a first request for a standard encryption algorithm
https://www.cryptologie.net/article/361/nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls/
|-
 
| 27 August
=== SSH ===
| 1974
SSH Communication
| NBS publishes a second request for encryption algorithms
 
|-
Version 1, 1.3, 1.5
| 17 March
 
| 1975
Version 2
| DES is published in the ''Federal Register'' for comment
 
|-
OpenSSH
| August
 
| 1976
ssh -v
| First workshop on DES
 
|-
https://www.sftp.net/specification
| September
 
| 1976
channels
| Second workshop, discussing mathematical foundation of DES
 
|-
Sch
| November
 
| 1976
Port forwarding
| DES is approved as a standard
 
|-
X-Forwarding
| 15 January
 
| 1977
hardening
| DES is published as a FIPS standard FIPS PUB 46
 
|-
sshd_config
| June
 
| 1977
ssh key agent
| [[Whitfield Diffie|Diffie]] and [[Martin Hellman|Hellman]] argue that the DES cipher can be broken by brute force.<ref name="dh-exh"/>
 
|-
key format
|
 
| 1983
authorized_keys
| DES is reaffirmed for the first time
 
|-
putty, securecrt, mindterm
|
 
| 1986
windows openssh in terminal
| [[Videocipher]] II, a TV satellite scrambling system based upon DES, begins use by HBO
 
|-
ftp / ftps is ftp over ssl, Microsoft IIS
| 22 January
 
| 1988
=== Azure ===
| DES is reaffirmed for the second time as FIPS 46-1, superseding FIPS PUB 46
 
|-
Login-AzureRmAccount
| July
 
| 1991
Get-AzureRmSubscription
| Biham and Shamir rediscover [[differential cryptanalysis]], and apply it to a 15-round DES-like cryptosystem.
 
|-
Select-AzureRmSubscription -SubscriptionName "janmg-azure"
|
 
| 1992
$VirtualMachine = Get-AzureRmVM -ResourceGroupName "janmg-k8s" -Name "k8s-master-61270158-0"
| 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.
 
|-
$sshPublicKey = Get-Content "$env:USERPROFILE\Documents\janmg.pub"
| 30 December
 
| 1993
$VirtualMachine = Add-AzureRmVMSshPublicKey -VM $VirtualMachine -KeyData
| DES is reaffirmed for the third time as FIPS 46-2
 
|-
== Wireguard ==
|
wg-quick v.s. wg (format of allowed address is different)
| 1994
 
| The first experimental cryptanalysis of DES is performed using linear cryptanalysis (Matsui, 1994).
first allowedip is it's own tunnel address.
|-
 
| June
keys exchanged before hand
| 1997
 
| The [[DESCHALL Project]] breaks a message encrypted with DES for the first time in public.
0.0.0.0/0 is everything, it's the default route
|-
 
| July
0.0.0.0/1 and 128.0.0.0/1 are also everything, but more specific, therefor overriding the default if set.
| 1998
 
| The [[Electronic Frontier Foundation|EFF]]'s [[EFF DES cracker|DES cracker]] (Deep Crack) breaks a DES key in 56 hours.
windows and android client
|-
 
| January
UDP/51920
| 1999
 
| Together, [[Deep Crack]] and [[distributed.net]] break a DES key in 22 hours and 15 minutes.
ProtonVPN support for Wireguard
|-
 
| 25 October
=== Server Example ===
| 1999
<[Interface]
| 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.
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
|-
ListenPort = 51820
| 26 November
| 2001
[Peer]
| The [[Advanced Encryption Standard]] is published in FIPS 197
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
|-
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
| 26 May
 
| 2002
=== Client Example ===
| The AES becomes effective
<[Interface]
|-
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
| 26 July
| 2004
[Peer]
| 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>
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
|-
Endpoint = 192.95.5.69:51820
| 19 May
AllowedIPs = 0.0.0.0/0
| 2005
The client example can be converted to a QR code with qrencode for easy installation on an android instance.
| 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>
|}


== PGP ==
=== CA Breach ===
Sending and receiving encrypted emails to others. https://futureboy.us/pgp.html
StuxNet, Duqu


PGP is Pretty Good Privacy introduced by Phil Zimmermann
Comodo (2011)


GPG is GNU Privacy Guard is an implementation of OpenPGP
DigiNotar (2011)


OpenPGP is the standard RFC4880 describing e.g. the v4 fileformats.
Turktrust (2012)
=== Passwords ===


=== Install ===
Algorithms
yum install gnupg
 
apt-get install rng-tools
https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm
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
https://password-hashing.net/
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
Argon2, Bcrypt and Pbkdf2
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
PBKDF2 RSA RFC 8018
gpg: key 3B1945D29AC3FBDA: public key "jan@janmg.com" imported
 
gpg: key 3B1945D29AC3FBDA: secret key imported
BCrypt Blowfish
gpg: Total number processed: 1
 
gpg:              imported: 1
SCrypt
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 ===
Linux Passwords


Obtain the customer's public key and import it. If they send the key in ascii format, write to a file and import.
Shadow
gpg --import customer.pub


Or if the you have a keyserver
https://github.com/shadow-maint/shadow/search?q=--crypt-method&unscoped_q=--crypt-method
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.
$1 = MD5 hashing algorithm.
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.
$2 =Blowfish Algorithm is in use.


=== Decryption ===
$2a=eksblowfish Algorithm
  gpg <encrypted file>
$5 =SHA-256 Algorithm
GPG will know what to do assuming the keys are imported.
$6 =SHA-512 Algorithm
Exporting Keys for backup
 
=== PAM ===
/etc/pam.d/common-password
 
=== HTTP Authorization Header ===
The header “Authorization” header for user password authentication has three modes, one basic where the “username:password” is based encoded. And one Digest where the username and password are MD5 hashed with a nonce for randomness.
Digest
Client request (username "Mufasa", password "Circle Of Life")
 
GET /dir/index.html HTTP/1.0
 
Host: localhost
 
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Bearer comes from OAuth2
 
SAML2
 
=== JWT ===
<nowiki>https://jwt.io</nowiki>
 
RFC 7520 JOSE JSON Object Signing and Encryption
 
JSON Web Signature (JWS)
 
JSON Web Encryption (JWE)
 
JSON Web Key (JWK)
 
JSON Web Algorithm (JWA)
 
JSON Web Token (JWT)
 
Python
 
Authlib, jose, pyjwt, python-jose, JWCrypto
 
=== Secure Storage and Functions ===
TPM, HSM, Secure Elements, OP-TEE
 
RSA PKCS11
 
Block Mode and Forward Secrecy
 
IV Initialization Vector
 
Padding
 
=== Others ===
Key negotiation DH Ecliptic Curve / Prime pairs
 
Curve Issues
 
Export Grade DHE
 
https://www.cryptologie.net/article/361/nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls/
 
=== SSH ===
SSH Communication
 
Version 1, 1.3, 1.5
 
Version 2
 
OpenSSH
 
ssh -v
 
https://www.sftp.net/specification
 
channels
 
Sch
 
Port forwarding
 
X-Forwarding
 
hardening
 
sshd_config
 
ssh key agent
 
key format
 
authorized_keys
 
putty, securecrt, mindterm
 
windows openssh in terminal
 
ftp / ftps is ftp over ssl, Microsoft IIS
 
=== Azure ===
 
Login-AzureRmAccount
 
Get-AzureRmSubscription
 
Select-AzureRmSubscription -SubscriptionName "janmg-azure"
 
$VirtualMachine = Get-AzureRmVM -ResourceGroupName "janmg-k8s" -Name "k8s-master-61270158-0"
 
$sshPublicKey = Get-Content "$env:USERPROFILE\Documents\janmg.pub"
 
$VirtualMachine = Add-AzureRmVMSshPublicKey -VM $VirtualMachine -KeyData
 
== Wireguard ==
wg-quick v.s. wg (format of allowed address is different)
 
first allowedip is it's own tunnel address.
 
keys exchanged before hand
 
0.0.0.0/0 is everything, it's the default route
 
0.0.0.0/1 and 128.0.0.0/1 are also everything, but more specific, therefor overriding the default if set.
 
windows and android client
 
UDP/51920
 
ProtonVPN support for Wireguard
 
=== Server Example ===
[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820
[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
 
=== Client Example ===
[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0
The client example can be converted to a QR code with qrencode for easy installation on an android instance.
 
== PGP ==
Sending and receiving encrypted emails to others. https://futureboy.us/pgp.html
 
PGP is Pretty Good Privacy introduced by Phil Zimmermann
 
GPG is GNU Privacy Guard is an implementation of OpenPGP
 
OpenPGP is the standard RFC4880 describing e.g. the v4 fileformats.
 
=== Install ===
yum install gnupg
apt-get install rng-tools
systemctl start rngd
useradd -m our_user
chmod o+rw $(tty)su - our_user
chmod o+rw $(tty) must be run before using su to our_user otherwise the gpg agent won’t work, you won’t be able to enter your password with gpg
 
Generate new key pairs
gpg --gen-key
Please select what kind of key you want:
(1) RSA and RSA (default)
What keysize do you want? (2048)
Key is valid for? (0) 1y
Real name: janmg support
Email address: our_user@us.com
Comment:  janmg support group
 
gpg --full-generate-key
gpg --list-secret-keys
gpg --export -a --output public.asc jan@janmg.com
gpg --export -a --output public.pgp E8D557EDF7369B9FBC856E7C856FE6E99E21D7FC
 
pem2openpgp jan@janmg.com < private-key.pem | gpg --import
gpg: key 3B1945D29AC3FBDA: public key "jan@janmg.com" imported
gpg: key 3B1945D29AC3FBDA: secret key imported
gpg: Total number processed: 1
gpg:              imported: 1
gpg:      secret keys read: 1
gpg:  secret keys imported: 1
 
=== Publishing ===
Export key in ASCII format to upload on webserver
gpg --export -a user@us.com
-----BEGIN PGP-----
AAA...
-----END PGP-----
 
upload to key servers.
gpg --keyserver pgp.mit.edu --send-keys 27B88533
gpg: sending key 27B88533 to hkp server pgp.mit.edu
 
=== File Encryption ===
 
Obtain the customer's public key and import it. If they send the key in ascii format, write to a file and import.
gpg --import customer.pub
 
Or if the you have a keyserver
gpg --keyserver pgp.mit.edu --search-keys our_user@customer.com
(or you can specify the fingerprint if they give it to you)
gpg --keyserver pgp.mit.edu --recv-keys <FINGERPRINT>
You can verify and see what keys have been imported
gpg --list-keys
Encrypt the file. In this example, the receiver of the encrypted file will be user@customer.com and the encrypted file is called testfile.
gpg --encrypt --sign -a -r user@customer.com our_user@us.com testfile
 
A new file will be created, called testfile.asc. It is readable as ASCII (the -a flag does this) so it can be pasted into an email.
If you want to encrypt as a binary, don't use the -a flag. In this case the extension is .gpg and it's a binary file.
 
=== Decryption ===
  gpg <encrypted file>
GPG will know what to do assuming the keys are imported.
Exporting Keys for backup
  gpg --export -a -o mypublickey.txt user@us.com  
  gpg --export -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
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
hkp://keyserver.ubuntu.com:80
 
 
The keys for ubuntu are also available with a webbrowser.
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/


<nowiki>http://keyserver.ubuntu.com/</nowiki>
=== Python ===
https://pycryptodome.readthedocs.io


== JOSE ==
=== Golang JOSE ===
[https://datatracker.ietf.org/doc/html/rfc7516 rfc7516]
[https://datatracker.ietf.org/doc/html/rfc7516 rfc7516]


Line 2,289: 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"