Securing Online
Communication
HTTPS, TLS, Certificates, RSA and Digital Signatures
GROUP 46
S/N Student’s Name Reg No. Course
1. Gladness I. Mathew 2022-04-06637 CEIT
2. Regina L. Mwigune 2022-04- 13605 CEIT
3. Andrew B. Sandy 2022-04-11903 CEIT
4. Rwegasila K. Byabato 2022-04-00982 CEIT
Introduction to Cryptography
Cryptography is a core component of cybersecurity. It secures sensitive
information and enables safe communication.
Encryption transforms plaintext into unreadable ciphertext using algorithms
and keys.
Historical methods like Caesar Cipher and Transposition Cipher show early
cryptographic approaches but are now vulnerable to brute force and frequency
analysis.
Symmetric Encryption (e.g., DES, AES) uses the same key for encryption and
decryption. It is efficient but not scalable for large networks due to complex key
management.
Asymmetric Encryption (e.g., RSA) uses a public-private key pair, allowing
secure communication without the need for secure key exchange.
Hash Functions generate fixed-size digests from data inputs, ensuring integrity
and supporting functions like HMAC, password hashing, and SSL/TLS.
Password Security practices such as salting and key derivation functions
enhance credential protection in databases.
Summary: Cryptography underpins confidentiality, integrity, and authenticity in
secure systems and communications.
Introduction to TLS/SSL and
HTTPS
Transport Layer Security (TLS) (and its predecessor,
Secure Sockets Layer (SSL)) is a cryptographic
protocol designed to provide communications security
over a computer network.
Its primary aims are privacy (confidentiality), integrity, and
authenticity through the use of cryptography between
communicating applications.
TLS runs "on top of some reliable transport protocol (e.g., TCP)".
Applications often use TLS as if it were a transport layer, but
developers must actively control initiating TLS handshakes and
handling exchanged certificates.
While used in various applications like email, instant messaging,
and VoIP, TLS's most publicly visible use is in securing HTTP traffic,
which constitutes the HTTPS protocol.
Encrypting HTTP Using
SSL/TLS
How HTTPS Works
HTTPS protects data (e.g., passwords, card details)
between clients and servers.
HTTPS = HTTP + SSL/TLS for encrypted, secure
communication.
SSL (Secure Socket Layer) and its successor TLS
(Transport Layer Security) provide encryption,
authentication, and data integrity.
Encrypting HTTP Using
SSL/TLS
Purposes of SSL
Verifies server identity.
Ensures only server reads client data and vice versa.
The Role of Digital
Certificates
A digital certificate serves to certify the ownership of a
public key by the named subject of the certificate.
It also indicates certain expected usages of that key.
Digital certificates allow other parties (relying parties)
to rely upon signatures or assertions made by the
private key that corresponds to the certified public key.
In the context of TLS, certificates are crucial for
authentication, certifying the integrity of a website and
confirming that visitors are connecting to the correct
server.
The Role of Certificate
Authorities (CAs)
TLS typically relies on a set of trusted third-party certificate
authorities (CAs) to establish the authenticity of certificates.
Trust in CAs is usually anchored in a list of certificates distributed
with user agent software (like web browsers).
Certificate authorities are necessary in a Public Key Infrastructure
(PKI) to verify the relationship between a certificate and its owner,
and to generate, sign, and manage certificate validity.
Choosing X.509 certificates means CAs are needed for this
verification process.
However, CAs can also be a weak point from a security
standpoint, potentially allowing man-in-the-middle (MITM) attacks
if the CA cooperates or is compromised.
How TLS Provides Security
Privacy (Confidentiality): Data is encrypted using a
symmetric-key algorithm. The symmetric keys are
generated uniquely for each connection based on a
shared secret negotiated at the start of the session.
Authentication: The identity of the communicating
parties can be authenticated using public-key
cryptography. Server authentication is required, while
client authentication is optional.
Integrity: Each message includes a message
integrity check using a message authentication code
(MAC). This prevents undetected loss or alteration of
the data during transmission.
The TLS Handshake -
Establishing a Secure
Connection
Before exchanging information, the client and
server negotiate a stateful connection using a
handshaking procedure.
This handshake uses an asymmetric cipher to
establish cipher settings and a session-
specific shared key for symmetric encryption.
All key data is derived from a "master secret",
which is computed from random numbers
generated by both client and server and a
"PreMasterSecret".
Digital Signatures in the
Handshake
Digital signatures are used as part of the
authentication process during the TLS handshake.
When a client authenticates, it sends a
CertificateVerify message.
This message is a signature over the previous
handshake messages using the client's certificate's
private key.
The server can then verify this signature using the
client's certificate's public key.
This process lets the server know that the client has
access to the private key corresponding to the
certificate and therefore owns the certificate.
Simple Real-Life Scenario: Basic
Website Connection (HTTPS)
1. ClientHello: Web browser connects to a TLS-enabled server and sends
supported TLS version, random number, cipher suites, and compression
methods.
2. ServerHello: Server responds with selected protocol version, cipher suite,
and its own random number.
3. Server Certificate: Server sends its digital certificate with its public
encryption key.
4. Client Verification: Browser validates the server's certificate.
5. ClientKeyExchange: Browser generates PreMasterSecret, encrypts it
with server's public key, and sends it.
6. Key Computation: Both compute a master secret from random values
and PreMasterSecret.
7. Handshake Completion: Confirm switch to new cipher suite and keys.
8. Secured Data Exchange: Communication is encrypted using session
keys, each message includes a MAC for integrity checking.
Challenges in certificate
Revocation.
Certificate Revocation Mechanisms:
• Certificate Revocation Lists (CRLs):
Lists of revoked certificates published by
CAs. Clients must download and check
these lists to verify certificate validity.
• Online Certificate Status Protocol
(OCSP): Allows clients to query the CA in
real-time to check the revocation status of
a specific certificate.
Challenges in certificate
Revocation.
Practical Issues:
• Latency and Privacy Concerns: OCSP checks can
introduce latency and may expose user browsing habits to
CAs.
• Availability: If OCSP responders are unavailable, browsers
often default to a "soft-fail," accepting the certificate
without confirmation of its validity.
• Ineffectiveness: Due to these issues, certificate revocation
mechanisms often fail to prevent the use of compromised
certificates in practice.
Implications:
• Attackers with access to a compromised certificate and its
private key can perform man-in-the-middle attacks, as
browsers may not effectively check revocation status.
Getting a Root CA Accepted
in Systems and Browsers.
Certification Requirements:
• CAs must be audited and certified by recognized authorities like
WebTrust.
• They must demonstrate secure key management, proper validation
processes, and adherence to strict operational policies.
Browser and OS Trust Stores:
• Operating Systems: Maintain their own list of trusted root CAs.
• Browsers: Some, like Firefox, maintain their own trust stores, while
others rely on the OS's trust store.
Inclusion Process:
• CAs must apply to each browser and OS vendor separately,
providing evidence of compliance with their specific requirements.
• The process is rigorous to ensure that only trustworthy CAs are
included, maintaining the integrity of the PKI system.
Fun Fact
Alice and Bob represent two secure communicators;
Eve is the eavesdropper used in cryptographic examples.
ROOMS-PROOFS
BYABATO46@COICT.rar
