TLS

https://www.misterpki.com/cryptojs/

https://ciphermachinesandcryptology.com/

https://access.redhat.com/articles/3642912

https://security.stackexchange.com/questions/216065/extracting-openssl-pre-master-secret-from-nginx#216456

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.

	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
Asymettric 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.2, SHA-512, ECDHE, AES-256-GCM or better, TLSv1.3, SHA3, EC

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.

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

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 keylength.com 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-RSA

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

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

256 15360

512

ECDLP ℓ(q) 256 512

Pairing ℓ(pᵏⁿ)

ℓ(p), ℓ(q) 6144

256 15360

512

US - Commercial National Security Algorithm (CNSA) Suite

	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

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 (SECRET) Parameters (TOP SECRET) Encryption AEAD ChaCha20-Poly1305 ChaCha20-Poly1305 Key Exchange ECDH DH Curve25519 Curve448 Digital Signature EdDSA XMSS LMS Ed25519 XMSS LMS Ed448 XMSS LMS Key Derivation HKDF SHA-256 SHA3-256 SHA-384 SHA3-384

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. IKEv1 and AH should not be used.

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

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.

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

Origin of Certificates

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

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

TLS certificates are based on ITU-T X.509v3 standards first developed for the X.500 Directory. It uses ITU-T ASN.1 for byte-packing structures in a TLV Type-Length-Value format DER. To transfer bytes, private keys and certificates can also be encoded as PEM which is the Base64 representation, wrapped with a start and an end line.

Netscape SSL, of which SSLv3 from 1996 was the first usable encryption standard for the web. IETF took over the development and renamed SSL to TLS. The internal version number for TLSv1.3 is 0x0304. TLS certificates incorporate the public key, a serial, criteria for validity, a url for certificate revocation, a subject (optionally also SAN), an issuer who signed the certificate. The certificate can therefor be trusted if the issuer certificate is included in the truststore.

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

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

OpenSSL

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

DSA

...

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

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

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

AES Challenge Response

Secure Protocols

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.

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

OSI Model, https://www.itu.int/rec/T-REC-X.210-199311-I/en

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

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 Handshake

After the initial TCP handshake (3 way SYN - SYN/ACK – ACK). TLS uses a 4-way handshake (ClientHello - ServerHello - ServerKey – ClientKey). Before the TLS version is negotiated the initial version in the ClientHello record is set to 1.0. The ClientHello itself states the maximum TLS version it can use. TLS 1.3 can use 0-RTT to reduce the roundtrips and the version is negotiated as a list. https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL#The_SSL_Handshake

+ Indicates noteworthy extensions sent in the previously noted message.

• Indicates optional or situation-dependent messages/extensions that are not always sent.

{} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret. [] Indicates messages protected using keys derived from traffic_secret_N

https://blog.cloudflare.com/introducing-tls-1-3/

TCP Fast Open, TLS False Start

HTTPS

HTTP is a text based protocol over TCP. HTTPS is an HTTP connection wrapped in a TLS connection over TCP. HTTPS is a different scheme. IANA has assigned TCP/80 to HTTP servers and TCP/443 to HTTPS servers (by default). Similarly, LDAP is assigned default TCP/389 and LDAPS is TCP/636. In Linux these default port assignments can be found in /etc/services. The alternative to different assigned port numbers dedicated for TLS is to use StartSSL to upgrade a regular TCP to TLS. HTTP does not support StartSSL, instead an HTTP 301 redirect is used to redirect to the HTTPS location. HTTPS on TCP/443 is using the HTTP protocol wrapped around TLS. Often only the server offers a certificate to authenticate itself to the client. But with a personal client certificate installed in the client, mutual authentication can be done. A full URL should contain the schema defines if TLS should be negotiated first. schema://domainname:[port]/ https://domain.name.com:443/

SSH

SSH has defined it’s own protocols similar to TLS. It’s using the same components and negotiations like Keyexchange, Encryption and IV. Since 2006 the version of the SSH Protocol should be SSHv2 only. SSH is most frequently used for remote terminal (secure shell) but it’s subsystem can also be used for SFTP for file transfers over the SSH channel.

Putty format, OpenSSH format

IPsec

IPsec originates as header for IPv6 and has been ported as protocol on IPv4. RFC 4301

The spelling "IPsec" is preferred and used throughout this and all related IPsec standards.  All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated.  However, any capitalization of the sequence of letters "IPsec" should be understood to refer to the IPsec protocols.

IPsec has an AH header for signing the IP packets with hashes, so that the protocols are in clear text, but the receiver can verify the traffic comes from the sender. IPsec has an ESP header that provides encryption. IPsec can be used in transport mode between two end-points or in tunnel mode to route traffic from one network to another network over a secure route.

IPsec can be used in transport mode between two end-points as client to server mode or in tunnel mode to route traffic from one network to another network over a secure route. In that case both sides can be an initiator that starts the connection(s)

Phase I, Negotiate Setting, e.g. with IKE

Phase II, Establish connection.

https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html

IKEv1

Oakley protocol and ISAKMP. RFC 2409 obsoleted by IKEv2

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

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.

X.509v3 certificates are the public parameters that define the validity of the certificate. The certificate should have a matching private key that must be kept safe. Important parameters are the validity period, the subject and the issuer who signed the certificate and the signature of the private key. In v3 extension attributes were introduces, key usage and subject alt name 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 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 Netscape has adopted X.500 into SSL and IETF has created profiles to use X.509 certificates for instance for Webservers and Email.

Version	Specification	Date	Security
X.509v1	T-REC-X.509/en July 1988	
X.509v2		1993	
X.509v3		June 1996	Additional extension fields
IETF PKI	RFC2459 January 1999	Profiles for applicability
IETF PKI	RFC3280 April 2002	
IETF PKI	RFC5280 May 2008

TLS uses X.509 certificates. the subject and keyUsage. Certificates have a typical lifetime of maximum 3 years. Intermediate certificates may have a 10 years expiry and root certificates are often valid for multiple decades.

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

File format

DER is an ASN.1 file format. PEM is a DER in Base 64. Keys can be

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

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 8.2 Docker

Docker registries by default have to be HTTPS. The alternative is to mark the registry in all the clients as INSECURE or to use selfsigned certificates and add the certificates

-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

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 owns port TCP/80 or TCP/443 and spawns sub-processes under an unprivileged user. For performance reasons it’s possible to terminate TLS connections in a loadbalancer like Cisco ACE 30 or BIGIP F5. 9.2 Browsers The CA / Browser forum is a group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS and code signing. The CA’s are the companies that sign certificates after they verified the owner. Browsers and Operating Systems have a root store with default CA certificates to trust. All certificates in the chain that are signed by the CA ROOT are then trusted. You can add or remove certificates. https://cabforum.org/browser-os-info/

Owner Root Store Adobe www.adobe.com/security/approved-trust-list.htm

Mozilla Overview of All CA-Related Mozilla Documentation Mozilla Root Certificate Program Microsoft aka.ms/RootCert Microsoft Root Certificate Program

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.

9.3 TLS 1.2 Support The versions of clients that can initiate TLSv1.2 connections should be at least. • Android 4.4.2 • Firefox 32 • IE 11 • IE Mobile 11 • Java 8 • Safari 7

TLS 1.3 Support TLS 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 https://tools.ietf.org/html/rfc8446 Firefox 63 and Chrome 70 in October 2018 will support TLS 1.3 as 0x0304. Older versions support Draft 28 as 0x7F1C.

https://github.com/mozilla/gecko-dev/blob/.../security/nss/lib/ssl/sslproto.h 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

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

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

...

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.1	eol	May 2018	First version to support TLS 1.3	el8 1.1.1k
3.0		Q4 2020	Redesign with providers
3.1
3.2

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

Configration options don't seem to matter

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

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

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

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

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

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/

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