TLS and Packet Filtering

• unwanted traffic

• unsecure computer from attacks from the internet

• attacks against protocols or services that the firewall blocke

stateless:

• make NEW decision for every packet not considering any state (e.g. established…)

• => decision only based on infor related to packet (and thus contained in packet like IP addresses, ports, protocols, …)

Stateful:

• keep track of state of network connections

• e.g. know wether incominc packet belongs to already established ftp connectoin

• -> take state of connectoin packet belong to into consideration

• whitelisting

  • deny all except rules state otherwise

  • hard to manage (has to consider everything that should be whitelisted to not break some functionality); more secure

• blacklisting

  • allow all except rules state otherwise

  • less secure but easier to manage

• attacks on the firewall itself

• malware

• viruses

• social engineering

• internal attacker

• tunnelled traffic that is forwarded by an internal host

• when the webserver is in a DMZ

• confidentiality

  • only entiteled entities may be able to read the data

• integrity

  • tampering with message will be detected

• authenticity

  • communicating parties can be identified / verified

• non-repudiation

  • communication partner cannot deny a message originated from him

• forward secrecy

  • compromise at this point in time does not lead to compromise of past connections

• attacker attacks cipher and has ability to let his chosen plaintext be encrypted

• -> can perform crypto analysis…

• active attacker

• -> can manipulate and forge messages…

• authenticators such as MAC tags …

• attacker can get authentication tag for arbitrary messages by requesting encryption

• -> but cannot compute valid authenticatoin tag for a new message itself…

• => Security under chosen ciper text attack

• -> provides message authentication

• private-key cryptography (symmetric cryptography)

• public-key cryptography (asymmetric cryptography)

• parties have exchanged the key securely…

• usually 128 bit

• different keys have be used for each comm. directoin and each purpose

• -> encryption and authentication…

• encryption:

  • AES-CTR

  • ChaCha20

• MACs:

  • HMAC-SHA2

• confidentiality

• authentication

• key exchange

• each participant has

  • private key

  • public key

• signatures -> created with private key, verified with corresponding public key

• provide authenticity and non-repudiation

• slower than symmetric crypto

• -> used for handshakes in order to generate shared secred keys (diffie hellman)

• attached to message to provide assurances of the sender and integrity of the message

• data structures that bind key values to subjects

• link identity to a pub key

• => private key only known by the identity certifed…

• by a trusted third party

• -> signs the certificate with its private key

• => pub key usually shipped in e.g. os, allowing to check the certificate…

• alice was there when bob signed it -> bob personally provides pub key

• alice has already bobs key and thus can compare it

• alice trusts trusted third party

• transport layer security

• Secures layer 4 traffic

• SSL

• secure socket layer

• drop of support for older, less secure cryptographic features

• accelerated TLS handshake

  • one RTT instead of two; support for 0-RTT

• => faster and more secure in a nutshell

• => already have pre-shared key

  • either obtained externally

  • or from previous handshake process

• transmit data at the first flight

• -> as it can already be encrypted…

• RSA key transport (no forward secrecy)

• CBC mode ciphers

• RC4 stream cipher

• arbitrary diffie-hellman groups

• exchange keys without having anyone get to know them

• or to generate it themselves

• wile partners share same key

• alice and bob aggre on two parameters, g and p, for key creation

• -> e.g. alice simply sending them to bob

• then both generate random number

  • only known to them…

• alice computes A = g^a mod p

• bob cmoputes B = g^b mod p

• => transmit A and B to partner

• => shared key K = B ^a mod p = A ^b mod p…

• sessino / application

• Enc(X, MAC(X))

• -> hash then encrypt

• symmetric cryptography

• -> as it is much faster than assymetric encryption

• protocol

• key exchange method

• authentication algorithm

• cipher for data transfer

• Message authentication code (MAC)

• no -> client and server are able to negotiate it

• no, not unless QUIC is used

• -> requires reliable transport layer protocol

• no

• -> there exists the option of ‘no encryption’

• no

• no

• no

• -> pairwise key exchange…

• no

• yes

• no

• -> requres way to verify that the pub key belong to communication partner…

• -> and that the communication partner is who he is…

• certificates

• and PKI

• => trusted third parties that ensrue this…

• the certificate authority (CA)

• have CA (institution) with public key

• CAs issue certificates (pub key <-> identity linkage)

• registration authorities sign these with their private key (often the CA itself)

=> Have to trust CA …. (RA)

• have certificates themselves

• -> continue verifying until reach root CA -> self-signed certificate…

  
  

• trust root CA

• -> can verify certs that were signed by it

• -> trust CA that have these

• -> …

=> usually browser comes up with pre-installed list of trusted CAs

• certificatoin request

• -> provdie identity (e.g. company name), distinguished name (i.e. domain name), public key

• key pair created locally by server, private key kept secret

• => wrap data in certification request (PKCS#10 format)

• has to be signed with private key (to ensure server has private key…)

• receiving the request, CA has to verify CSR (e.g. show up with passport, …)

• -> if verified, CA issues signed certificate (e.g. X.509)

• certificaet sent along with signed, hashed version of the certificate

• certificate contains servers public key and string which identifies the server

• CA uses its private key to sign the servers certificate

• no, bottom up until we reach the root (or already trusted CA)

• not a single authority

• -> scaling

• -> if single, who should it be=

• -> single point of attack…

• no -> only one

• to have a trusted third paryt

• to sign certificates

• it is

  • tool to protect inforamtion in computer systems

  • basis of many security mechanisms

• its not

  • holy grail solving all security problems

  • sth one should invent or implement oneself

• security should not be acheived by obscurity…

• chop up the data into blocks of equal size, pad the last block

• encrypt all blocks

examples:

• electronic codebook

• cipher block chaining

• ciper feedback

• output feedback

• counter

• key stream xor plaintext

• -> key stream generated by key and nonce

• error detection

• computational overhead

• increase of message lenght

• vs

• error deteciton or even correction…

• cryptographioc hash functions

• -> ensure integrity

• but completely other topic whether integrity was broken on purpose (or sth like transmisison error…)

• should be computatonally infeasible to recalculate them…

• => and by thus comp. infeasible to forge it

• message authenticaion codes

• one way function

• easy to compute

• variable length input

• fixed length output

• first pre image resistancy (one way fct)

  • x -> y : given y, comp. infeasible to calculate x

• second pre image resistance

  • given x, cannot find other x’ that maps to same y (comp infeasibe)

• collision resistance

  • cannot efficiently find pair x, x’ that map to same y (second pre image -> one x was given…)

• random oracle property

  • computationally infeasible to distinguish y from random n-bit value

• applying only crypt hash not sufficient…

• => Kerckhoffs principle -> hash functions are known

• -> need to protect them…

• include secret in hash value…

• => only person with secret can re-calculate hash value… (=> MAC)

• prove message integrity

• detect tampering

• cannot be forged

• can be replayed

• depends on definition and scenario

• if k shared between alice an bob and k only used by alice to compute MACs of messages from her to bob

  • -> bob can be sure its alice

• if k shared group key -> not sure who sent it

• also, external observer cannot validate MAC

• ciphers and authenticaion (most of them) require common, pre-shared secret key

• out of band sharing not always an option

• key exchange needs to be conducted securely

• vast amount of symm. keys needed if one for each comm. partner… => O(n^2)

• => with symmetric: everyone has single key pair -> 2n (O(n))

• signing function S(m, sk) -> sigma (signature)

  • sk: signing key / secret / privat key

• verification funciton V(pk, m, sigma) -> True/False

• the message and the signature (sigma)

• -> can be verified by applying verificatoin function to the message, the signa and the public key…

• code signing

• certificates

• pubilc keys need to be managed

• computationally more expensive due to math properties

• => often hybrid used (DH key exchange)

• use assym. crypto for authenticaiton and key exchange / establishement

• use symmetric encryption for real data transfer

• => TLS makes use of this…

• confidentiality

• integrity (with hashes)

• authenticity (somewhat)

• no key exchange

• confidentiality

• integrity (with signatures)

• authenticity

• key exchnage

• use certificates and signatures to vlaidate public key

  
  

• validate ownership over domain

• -> publish DNS TXT record with challenge value

• -> publish nonce provided by issuer

• respond to email sent to mail in whois

• …

• pub key

• entity name

• vaildity period

• signer information

• + signature over all these files

=> signed with private key of CA

• issued by CA

• prove control over domain to CA -> e.g. DNS TXT, nonce on website, respond to mail,…

• CA signs with private key

  • your pub key, other certificate information

• certificate is sent to you

• e.g. when private key is compromised

• collected in signed certificate revocation list

• query the CA with the online certificaet status protocol (OCSP)

• esentially unsolved right now

• trusted CA has signed it

• name correct

• validity period not over

• valid signature

• not revoked

• voluntary association

• negotiates rules and controls for issuance

• different levels of assureances without security benefit

• many trusted CAs

• very difficult to remove CAs

• any CA may sign a certificate for anyone, anywhere

• tons of misissuances • CAs by governments

• CAs have been compromised

• CAs have sold person-in-the-middle boxes

• certificate revocation problematic

• complicated format

• irrevocably publish issuances

• enable everybody to check if presented certificate was published

• no hiding of misissuances anymore

  
  

• open and public

• multiple logs

• efficient check if certificate is in log

• efficient check if only append operations have been done in this log

• Chrome demanded CT starting April 2018

• Safari demanded CT starting October 2018

• Firefox: unclear, some work has been done

• above TCP

• confidentiality and data integrity

• peer authenticatroin

• client-server principle

• transparent for applications e.g. IMAPS, HTTPS

• handshake

• change cipher spec

• alert

• application data

• record

• e.g. private key compromised

• collected in signed certificate revocation list

• -> query the CA with the online certificate status protocol

• sub protocol of TLS

• -> responsible for verifying integrity and origin of application data

• -> responsible for its securing

-> random, DH

x random, DH, compute DH

<- random, cert, DH, signature(DH, randoms)

x compute DH, verify certificate, verify signature, compute auth

• 1-RTT: DH

  • DH moved into clientHello, serverHello

  • authenticatio: hash over all messages signed with server public key

• 0-RTT:

  • server sends long-term DH public key previously

  • client uses this for encrypting first message

• 1.3

• 1.2 with GCM

• packet traversal rules

• rule: match header and take action

• modules provide wide variety of matching options

• actions. go to other chain, drop, accept, reject, SNAT

• rules added to empty predefined and custom chains

• chains organized in tables

• client sends list of supported cipher suites to server

  • -> server chooses

• choice of actual suite provided in server hello