DISTRIBUTION OF PUBLIC KEYS

Several techniques have been proposed for the distribution of public keys.
Virtually all these proposals can be grouped into the following general schemes:

• Public announcement

• Publicly available directory

• Public-key authority

• Public-key certificates

Public Announcement of Public Keys

On the face of it, the point of public-key encryption is that the public key is
public. Thus, if there is some broadly accepted public-key algorithm, such as
RSA, any participant can send his or her public key to any other participant or
broadcast the key to the community at large (Figure 14.9). For example, because
of the growing popularity of PGP (pretty good privacy, discussed in Chapter
18), which makes use of RSA, many PGP users have adopted the practice of
appending their public key to messages that they send to public forums, such as
USENET newsgroups and Internet mailing lists.
Although this approach is convenient, it has a major weakness. Anyone can
forge such a public announcement. That is, some user could pretend to be user
A and send a public key to another participant or broadcast such a public key.
Until such time as user A discovers the forgery and alerts other participants, the
forger is able to read all encrypted messages intended for A and can use the
forged keys for authentication (see Figure 9.3).

A publicly available directory of public keys, maintained by

a trusted authority, ensures secure communication by listing
verified {name, public key} pairs. Participants register their
keys through secure, authenticated methods, and can update
them anytime, such as when a private key is compromised or
for added security. This system guarantees trust in the listed
keys, as they are authenticated and managed by a reliable
organization.
 A public-key authority enhances security by tightly controlling key distribution and verifying
authenticity. A central authority maintains a directory of public keys and possesses a private-public
key pair known to all participants. When A requests B's public key, it sends a timestamped request to
the authority. The authority responds with a message encrypted using its private key, which A
decrypts using the authority’s public key. This message contains B’s public key (for secure
communication) and the original request (to verify integrity and match the response to the request).
This ensures the key's authenticity and prevents tampering.

• The original timestamp given so A can determine that this is not an

old mes-sage from the authority containing a key other than B’s current public
key
3. A stores B’s public key and also uses it to encrypt a message to B
containing an identifier of A (IDA) and a nonce (N1), which is used to identify
this transaction uniquely.
4, 5. B retrieves A’s public key from the authority in the same manner as A
retrieved B’s public key.
At this point, public keys have been securely delivered to A and B, and they
may begin their protected exchange. However, two additional steps are
desirable:

6. B sends a message to A encrypted with PUa and containing A’s nonce

(N1) as well as a new nonce generated by B (N2). Because only B could
have decrypted message (3), the presence of N1 in message (6) assures A that
the correspondent is B.

6. A returns N2, which is encrypted using B’s public key, to assure B

that its cor- respondent is A.

Thus, a total of seven messages are required. However, the initial four mes-
sages need be used only infrequently because both A and B can save the other’s
public key for future use—a technique known as caching. Periodically, a user
should request fresh copies of the public keys of its correspondents to ensure
currency.

Public-Key Certificates

Certificates provide a secure way to share public keys without needing to

contact a central authority every time. A certificate is a document issued by a
trusted organization, called a Certificate Authority (CA). It contains a person's
public key, their name or ID, and is signed by the CA to prove it’s authentic. To
get a certificate, a person securely provides their public key to the CA, which
creates and issues the certificate.

The certificate can be shared with anyone, who can then verify its authenticity
using the CA’s public key. Certificates also include timestamps to ensure they
are current and to prevent misuse if someone’s private key is stolen. This
timestamp works like an expiration date, making old certificates invalid. The
X.509 standard is widely used to format certificates and is essential in securing
online communication, such as in HTTPS, email encryption, and VPNs.

1. Any participant can read a certificate to determine the name and

public key of the certificate’s owner.
2. Any participant can verify that the certificate originated from the
certificate authority and is not counterfeit.
3. Only the certificate authority can create and update certificates.

These requirements are satisfied by the original proposal in [KOHN78].

Denning [DENN83] added the following additional requirement:

4. Any participant can verify the currency of the certificate.

A certificate scheme is illustrated in Figure 14.12. Each participant applies to

the certificate authority, supplying a public key and requesting a certificate.

Application must be in person or by some form of secure authenticated

communication. For participant A, the authority provides a certificate of the
form
CA = E(PRauth, [T || IDA || PUa])

where PRauth is the private key used by the authority and T is a timestamp. A
may then pass this certificate on to any other participant, who reads and verifies
the certificate as follows:

D(PUauth, CA) = D(PUauth, E(PRauth, [T || IDA || PUa])) = (T || IDA || PUa)

The recipient uses the authority’s public key, PUauth, to decrypt the certifi- cate.
Because the certificate is readable only using the authority’s public key, this
verifies that the certificate came from the certificate authority. The elements IDA
and PUa provide the recipient with the name and public key of the certificate’s
holder. The timestamp T validates the currency of the certificate. The timestamp
counters the following scenario. A’s private key is learned by an adversary. A
gen- erates a new private/public key pair and applies to the certificate authority
for a new certificate. Meanwhile, the adversary replays the old certificate to B.
If B then encrypts messages using the compromised old public key, the
adversary can read those messages.

In this context, the compromise of a private key is comparable to the loss of a

credit card. The owner cancels the credit card number but is at risk until all
possible communicants are aware that the old credit card is obsolete. Thus, the
timestamp serves as something like an expiration date. If a certificate is
sufficiently old, it is assumed to be expired.

One scheme has become universally accepted for formatting public-key cer-
tificates: the X.509 standard. X.509 certificates are used in most network
security applications, including IP security, transport layer security (TLS), and
S/MIME, all of which are discussed in Part Five. X.509 is examined in detail in
the next section.

X.509 Authentication Service

X.509 is a digital certificate that is built on top of a widely trusted

standard known as ITU or International Telecommunication Union X.509

standard, in which the format of PKI certificates is defined. X.509 digital

certificate is a certificate-based authentication security framework that can

be used for providing secure transaction processing and private

information. These are primarily used for handling the security and identity

in computer networking and internet-based communications.

Working of X.509 Authentication Service Certificate:

The X.509 authentication service uses certificates like digital ID cards to

verify a user's identity. These certificates are issued by a trusted authority,

called a Certification Authority (CA), and stored in an online directory so

users can easily access them. Each certificate includes the user's public

key, which is paired with a private key to securely send or receive

messages.

Once a certificate is issued, it acts like an ID that the user can present

when accessing resources that require authentication. Because the

certificate is unique and securely issued, it’s much safer than using

passwords. This system ensures secure communication and reliable

identity verification.

Generally, the certificate includes the elements given below:

 ● Version number: It defines the X.509 version that concerns the

certificate.

● Serial number: It is the unique number that the certified authority

issues.

● Signature Algorithm Identifier: This is the algorithm that is used

for signing the certificate.

● Issuer name: Tells about the X.500 name of the certified

authority which signed and created the certificate.

● Period of Validity: It defines the period for which the certificate is

valid.

● Subject Name: Tells about the name of the user to whom this

certificate has been issued.

● Subject’s public key information: It defines the subject’s public

key along with an identifier of the algorithm for which this key is

supposed to be used.

● Extension block: This field contains additional standard

information.

● Signature: This field contains the hash code of all other fields

which is encrypted by the certified authority private key.

What is PGP?
Pretty Good Privacy (PGP) is an encryption software program software

designed to ensure the confidentiality, integrity, and authenticity of virtual

communications and information.

PGP (Pretty Good Privacy) secures data using a hybrid method that

combines symmetric-key and public-key cryptography. Symmetric-key

cryptography uses a single secret key for both encryption and decryption,

while public-key cryptography uses a pair of keys: a public key, shared

openly for encryption, and a private key, kept secret for decryption. This

combination makes PGP both secure and efficient.

The following are the services offered by PGP:

1. Authentication

2. Confidentiality

3. Email Compatibility

4. Segmentation

Note:

Authentication in PGP
Authentication basically means something that is used to validate

something as true or real. To login into some sites sometimes we give our

account name and password, that is an authentication verification

procedure.

In the email world, checking the authenticity of an email is nothing but to

check whether it actually came from the person it says. In emails,

authentication has to be checked as there are some people who spoof the

emails or some spams and sometimes it can cause a lot of inconvenience.

The Authentication service in PGP is provided as follows:

Authentication in PGP

As shown in the above figure, the Hash Function (H) calculates the Hash

Value of the message. For the hashing purpose, SHA-1 is used and it

produces a 160 bit output hash value. Then, using the sender’s private key

(KPa), it is encrypted and it’s called as Digital Signature. The Message is

then appended to the signature. All the process happened till now, is

sometimes described as signing the message . Then the message is

compressed to reduce the transmission overhead and is sent over to the

receiver.
At the receiver’s end, the data is decompressed and the message,

signature are obtained. The signature is then decrypted using the sender’s

public key(PUa) and the hash value is obtained. The message is again

passed to hash function and it’s hash value is calculated and obtained.

Both the values, one from signature and another from the recent output of

hash function are compared and if both are same, it means that the email

is actually sent from a known one and is legit, else it means that it’s not a

legit one.

2. Confidentiality in PGP
Sometimes we see some packages labelled as ‘Confidential’, which means

that those packages are not meant for all the people and only selected

persons can see them. The same applies to the email confidentiality as

well. Here, in the email service, only the sender and the receiver should be

able to read the message, that means the contents have to be kept secret

from every other person, except for those two.

PGP provides that Confidentiality service in the following manner:

Confidentiality in PGP
Then, the session key (Ks) itself gets encrypted through public key

encryption (EP) using receiver’s public key(KUb) . Both the encrypted

entities are now concatenated and sent to the receiver.

As you can see, the original message was compressed and then encrypted

initially and hence even if any one could get hold of the traffic, he cannot

read the contents as they are not in readable form and they can only read

them if they had the session key (Ks). Even though session key is

transmitted to the receiver and hence, is in the traffic, it is in encrypted

form and only the receiver’s private key (KPb)can be used to decrypt that

and thus our message would be completely safe.

At the receiver’s end, the encrypted key is decrypted using KPb and the

message is decrypted with the obtained session key. Then, the message is

decompressed to obtain the M.

RSA algorithm is used for the public-key encryption and for the symmetric

key encryption, CAST-128(or IDEA or 3DES) is used.

Practically, both the Authentication and Confidentiality services are

provided in parallel as follows :

 Authentication and Confidentiality services in PGP

PGP Operation – Compression

By default, PGP compresses the message after adding the signature but before encrypting it. This saves space

for email transmission and file storage. The compression algorithm used is ZIP.

● The signature is added before compression for two reasons:

1. It allows storing the uncompressed message with the signature for later verification.

2. Adding the hash and signature after compression would force all PGP versions to use the

same compression algorithm, which is not ideal since PGP compression is not deterministic.

● Encryption is applied after compression to improve security. Compressed messages have less

redundancy than the original text, making it harder for attackers to analyze.

PGP Operation – Email Compatibility

PGP makes encrypted data work with email systems that only support text. It converts the encrypted data into

readable text using radix-64 conversion, which changes 3 bytes of data into 4 text characters and adds

error-checking (CRC). This increases the size slightly, but compression still saves space overall.

PGP Operation – Segmentation/Reassembly

If a message is too large for email (e.g., over 50,000 bytes), PGP splits it into smaller parts after processing. The

session key and signature are included only in the first part. At the receiving end, PGP joins the parts back

together before decrypting or checking the signature.

Cryptographic Keys and Key Rings
PGP uses four types of keys:

1. One-time session symmetric keys: Used to encrypt and decrypt a

single message.

2. Public keys: Shared openly for encrypting messages.

3. Private keys: Kept secret for decrypting messages.

4. Passphrase-based symmetric keys: Created using a password for

encryption.

To manage these keys, PGP has the following requirements:

1. It needs a way to generate unpredictable session keys.

2. Users can have multiple public/private key pairs.

3. Each user must keep two key files: one for their public/private key

pairs and another for public keys of others.

PGP Session Keys

A session key is created for each message and used only for that message.

To generate it, random numbers are produced using the ANSI X12.17

algorithm. The randomness comes from user keystrokes, including the

keys pressed and the timing of each press.

Key Identifiers in PGP

In PGP, a user can have multiple public/private key pairs. When encrypting

or signing a message, the user needs to let the recipient know which key

was used. Instead of attaching the full public key (which is inefficient),

PGP uses a key identifier.

 ● The key identifier is a shorter value derived from the key.

● It is created using the least significant 64 bits of the public key,

which is highly likely to be unique.

● For example, the key ID for a public key PUa is PUa mod 2^ 64.

This key ID is sent with the message, making communication efficient. It is

also required for PGP digital signatures.

PGP Message Format

A PGP message has three main components:

1. Message Component: Contains the actual data (message), along

with a filename and timestamp marking the time of creation.

2. Signature Component (optional): Includes the following:

○ Timestamp: When the signature was created.

○ Message Digest: A 160-bit SHA-1 hash, encrypted with the

sender's private signature key.

○ First Two Octets of the Message Digest: Helps the recipient

verify the correct public key was used to decrypt the digest

and acts as a 16-bit error check for the message.

○ Key ID of Sender's Public Key: Identifies which public key

should be used to decrypt the digest, and indirectly identifies

the sender's private key.

3. Session Key Component (optional): Includes the session key for

encrypting the message, if required.

PGP Key Rings

In PGP, keys and key IDs are essential for secure communication. To manage these
efficiently, PGP uses two types of key rings:

1. Private-Key Ring: Stores the user's own public/private key pairs.

2. Public-Key Ring: Stores the public keys of other users the person communicates
with.

These key rings help organize and store keys systematically, making it easier for users to
encrypt, decrypt, and verify messages securely.

The Private-Key Ring is like a table where each row represents one public/private key pair
owned by the user. Each row includes the following details:

● Timestamp: The date and time when the key pair was created.
● Key ID: The least significant 64 bits of the public key.
● Public Key: The public key from the pair.
● Private Key: The private key, stored in an encrypted form for security.
● User ID: Usually the user's email address (e.g., [email protected]), but users can
assign different names (e.g., Stallings or WilliamStallings) or reuse the same User ID
for multiple key pairs.

The private-key ring is stored on the user's device and is accessible only to them. To make
the private key secure, it is not stored directly but is encrypted using CAST-128 (or
sometimes IDEA or 3DES). The process is:

1. The user selects a passphrase to encrypt private keys.

2. When creating a new key pair (using RSA), the system asks for the passphrase. It
generates a 160-bit hash of the passphrase using SHA-1 and discards the
passphrase.
3. The system encrypts the private key using CAST-128, with 128 bits of the hash code
as the key. The hash is then discarded, and only the encrypted private key is saved
in the private-key ring
b) Public-key Ring

This data structure is used to store public keys of other users that are known to this user.

Timestamp: The date/time when this entry was generated.

Key ID: The least significant 64 bits of the public key for this entry

Public Key: The public key for this entry.

User ID: Identifies the owner of this key. Multiple user IDs may be associated with a single
public key

Owner Trust in Public-Key Ring PGP includes a feature called Owner

Trust, which is a measure of how much the owner trusts the key's owner
to validate other keys.
Key legitimacy refers to the authenticity and trustworthiness of a public key. In PGP, it is
crucial to verify that a public key actually belongs to the person it claims to, so that encrypted
messages can be securely sent.

PGP Message Transmission and Reception

Message transmission The following figure shows the steps during message transmission
assuming that the message is to be both signed and encrypted.

Signature Trust Field A key ring owner collects all the signatures that are related to the
entries. Each signature has its own signature-trust-field that specifies the level of PGP user’s
trust towards the signer.
PGP Message Transmission – Sending Steps

1. Signing the Message:

○ a. Private Key Retrieval:
PGP retrieves the sender's private key from the private-key ring using the
user ID (e.g., your_userid) as an index. If the user ID is not provided, the first
private key in the ring is selected.
○ b. Passphrase Prompt:
PGP prompts the user to enter the passphrase to decrypt the private key,
ensuring that only the authorized user can use it.
○ c. Constructing the Signature:
PGP creates the signature component of the message, which is a digital
signature generated by encrypting the message digest with the sender’s
private key.
2. Encrypting the Message:
○ a. Session Key Generation:
PGP generates a random session key used for encrypting the message.
This session key ensures that encryption is fast and efficient.
○ b. Public Key Retrieval:
PGP retrieves the recipient's public key from the public-key ring using the
recipient's user ID (e.g., her_userid) as an index. This public key will be used
to encrypt the session key.
○ c. Session Key Component Construction:
PGP constructs the session key component of the message, which contains
the encrypted session key (encrypted with the recipient's public key).
Message Reception

Decrypting the Message:

● a. Private Key Retrieval:

PGP retrieves the receiver's private key from the private-key ring, using the Key ID
field in the session key component of the message as an index.
● b. Passphrase Prompt:
PGP prompts the user for the passphrase to decrypt the private key, ensuring only
the authorized user can access it.
● c. Session Key Recovery and Message Decryption:
PGP recovers the session key and uses it to decrypt the message, revealing the
original content.

Authenticating the Message:

● a. Public Key Retrieval:

PGP retrieves the sender's public key from the public-key ring, using the Key ID field
in the signature component of the message as an index.
● b. Recovering the Message Digest:
PGP extracts the transmitted message digest from the signature component.
● c. Message Digest Comparison:
PGP computes the message digest of the received message and compares it to the
transmitted digest. If they match, the message is authenticated, confirming its
integrity and verifying that it was sent by the expected sender.

RADIX-64 in PGP
Many electronic mail systems can only transmit blocks of ASCII text. This can cause a
problem when sending encrypted data since ciphertext blocks might not correspond to ASCII
characters which can be transmitted. PGP overcomes this problem by using radix-64
conversion.

PGP E-Mail Compatibility:

Example • Suppose the email message is:

ASCII format: 01101110 01100101 01110111 •

After encryption: 10010001 10011010 10001000 •

The problem after encryption: • the three bytes do not represent any key board ASCII
characters. • Most email systems cannot transmit and process such a piece of ciphertext

Radix-64 Conversion
Suppose the text to be encrypted has been converted into binary using ASCII coding and
encrypted to give a ciphertext stream of binary. Radix-64 conversion maps arbitrary binary
into printable characters as follows:

1. The binary input is split into blocks of 24 bits (3 bytes).

2. Each 24 block is then split into four sets each of 6-bits.
3. Each 6-bit set will then have a value between 0 and 2^6-1 (=63).
4. This value is encoded into a printable character.
SSL Overview – Simplified

SSL (Secure Sockets Layer) is a security method used to protect web-based applications. It
works over TCP (Transmission Control Protocol) to ensure a reliable, secure connection
between two parties. SSL is not just one protocol but a set of protocols that work together.
 ● SSL Record Protocol: This is the foundation layer of SSL and works directly with
TCP. It provides basic security features for higher-level protocols, like HTTP.
● Higher-Level Protocols: Several protocols use the SSL Record Protocol to ensure
secure communication:
1. Handshake Protocol: Helps establish a secure connection.
2. Change Cipher Spec Protocol: Changes the encryption keys for a session.
3. Alert Protocol: Sends alerts about any errors or issues in the
communication.

In short, SSL layers help ensure secure and reliable communication on the web.

SSL Record Protocol

The SSL Record Protocol is responsible for ensuring confidentiality and message integrity in
SSL connections.

Here’s how it works:

1. Confidentiality: This is achieved through encryption.

2. Message Integrity: It ensures data hasn’t been altered by using a Message
Authentication Code (MAC).

The protocol performs the following steps:

● Fragmentation: The application message is split into smaller blocks (each no bigger
than 16,384 bytes).
● Compression: The blocks are compressed, but the size increase must be small (less
than 1,024 bytes).
● MAC Calculation: A MAC is created over the compressed data using a shared secret
key, ensuring integrity. This MAC is added to the block.
● Encryption: The compressed data and MAC are then encrypted with symmetric
encryption, and the encrypted content must stay within a certain size limit (it can't
grow by more than 1,024 bytes).
● Header: A header is added with the following information:
○ Content Type (indicates which higher-level protocol is used, like HTTP,
Handshake, etc.)
○ Major and Minor Version (indicate which version of SSL is being used)
○ Compressed Length (indicates the size of the compressed data).

11.3 Change Cipher Spec Protocol

This consists of a single message which consists of a single byte with the value 1. This is
used to cause the pending state to be copied into the current state which updates the cipher
suite to be used on this connection.

11.4 Alert Protocol

The Alert Protocol in SSL is used to send important messages about problems or issues
during the connection. It has two parts: the first part tells if the alert is a warning
(non-critical) or fatal (serious, leading to immediate disconnection), and the second part
provides a code that explains the specific problem, like an invalid certificate or decryption
failure. This helps SSL manage and handle errors to keep the connection secure.
11.5 Handshake Protocol
This is the most complex part of SSL and allows the server and client to authenticate each
other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used
to protect data sent in an SSL record. This protocol is used before any application data is
sent. It consists of a series of messages exchanged by the client and server, all of which
have the format shown in figure 11.5. Each message has three fields:

. Type (1 byte): Indicates one of 10 messages such as “hello request” (see figure 11.4).
2. Length (3 bytes): The length of the message in bytes.
3. Content(≥ 0 byte): The parameters associated with this message such version of SSL
being used.
The Handshake Protocol is shown in figure 11.6. This consists of four phases:
Establish security capabilities,

Version: The highest version of SSL that the client supports.

Random: A combination of a 32-bit timestamp and a 28-byte random number (nonce), which
helps ensure that each session is unique.
Session ID: A unique identifier that represents a particular session. It can vary in length.
CipherSuite: A list of encryption algorithms that the client supports, ordered by preference.
This includes algorithms for key exchange, encryption (CipherAlgorithm), message
authentication (MacAlgorithm), and other parameters like key material size and initialization
vector (IV) size.
Compression Method: A list of methods the client can use to compress data during the
SSL connection setup.

2. In this step, the server sends its certificate (proving its identity), and if needed, a key
exchange message to set up encryption. It may also ask the client for its certificate,
especially if both sides need to authenticate each other. Once this is done, the server signals
the end of the "Hello" phase, preparing for the next steps in the handshake.

3.When the client receives the server's "done" message, it checks if the server's certificate is
valid and if the server's settings (like the SSL version and encryption methods) are
acceptable. If everything looks good, the client proceeds by sending a few messages back to
the server: if requested, it sends its certificate (or a "no certificate" alert if it doesn't have
one), followed by a key exchange message to set up the shared encryption key. The client
may also send a certificate verification message to confirm the authenticity of its certificate.
4. Once the client has sent all necessary messages, the next step is to change the cipher
suite and finalize the handshake process. This involves both the client and server agreeing
on the encryption methods and keys to use. After the cipher suite change, the secure
connection is fully established, and they can begin securely exchanging the actual data from
the application layer, like web pages or files.

Transport Layer Security (TLS) is a protocol that ensures secure communication between
two applications over a network. Developed by the Internet Engineering Task Force (IETF),
TLS provides authentication, privacy, and data integrity, making it crucial for secure data
exchanges. It's widely used in web browsers for secure browsing (HTTPS), file transfers,
VPNs, remote desktop connections, and VoIP. Additionally, TLS is being adopted in newer
technologies like 5G to secure network functions, ensuring safety across communication
channels in modern cellular networks.

How does Transport Layer Security work?

TLS uses a client-server handshake mechanism to establish an encrypted

and secure connection and to ensure the authenticity of the
communication. Here's a breakdown of the process:

1. Communicating devices exchange encryption capabilities.

2. An authentication process occurs using digital certificates to help
prove the server is the entity it claims to be.
3. A session key exchange occurs. During this process, clients and
servers must agree on a key to establish the fact that the secure
session is indeed between the client and server -- and not
something in the middle attempting to hijack the conversation.
In TLS, the public key exchange helps the client and server agree on a
secret key to keep their communication secure. This is done using two
main methods: RSA and Diffie-Hellman. In RSA, the client sends an
encrypted message with a secret key to the server, which decrypts it using
its private key. In Diffie-Hellman, both the client and server exchange public
keys and use math to create a shared secret without directly sending it.
Once this shared secret is established, they use it to encrypt their
communication, ensuring that no one can eavesdrop or tamper with the
data.
The challenges of TLS

There are a few drawbacks when it comes to either not using secure
authentication or any encryption -- or when deciding between TLS and
other security protocols, such as IPsec. Here are a few examples:

● Because TLS operates at Layers 4 through 7 of the OSI model, as

opposed to Layer 3, which is the case with IPsec, each application
and each communication flow between client and server must
establish its own TLS session to gain authentication and data
encryption benefits.
● The ability to use TLS depends on whether each application
supports it.
● Since TLS is implemented on an application-by-application basis
to achieve improved granularity and control over encrypted
sessions, it comes at the cost of increased management
overhead.
● Now that TLS is gaining in popularity, threat actors are more
focused on discovering and exploiting potential TLS exploits that
can be used to compromise data security and integrity.

Differences between TLS and SSL

ATTACKS

Here are some attacks against TLS:

1. Heartbleed: A bug in OpenSSL that let attackers read sensitive data

from the server, like passwords or private keys.
2. POODLE: Exploits weaknesses in SSL 3.0 encryption, allowing
attackers to decrypt data.
3. BEAST: Targets TLS 1.0 and breaks the encryption by exploiting how
it handles data blocks.
4. CRIME: Uses data compression to leak information and decrypt
session cookies.
5. BREACH: Similar to CRIME, but it exploits HTTP compression to
extract sensitive data from encrypted traffic.
6. Downgrade Attacks: Forces a weaker version of TLS or SSL,
making it easier to break encryption.
7. Weak Ciphers: Older, insecure encryption methods can be exploited
to decrypt traffic.