Cryptography 101 with SSL

To Start With

Whenever you are connecting to a site via HTTPS, the complete session is encrypted and all the
application data is sent over a secured encrypted channel.

HTTPS (Hypertext Transfer Protocol Secure) is not a protocol in itself but the SSL/TLS protocol tied on
top of HTTP protocol. So basically, Transport Layer Security (TLS) and Secure Socket Layer (SSL) are
the protocols which provide secure communication over the internet between the client and the server.

But how does this all work? From the moment you type https://www.example.com and it downloads the
website for you, there are plenty of operations going in the background.

Key Concepts

Before we proceed, let’s discuss why we need a secure channel and which key concepts are involved
here.

Consider a scenario where Alice wants to perform an online transaction with Bob and she is sharing her
credit card information with Bob. So her main worries would be:-

1. Confidentiality/Privacy: Whatever information Alice shares with Bob, she wants to keep it
private and confidential and safe from any eavesdropper.
2. Authentication: Alice also wants to make sure that whatever information she wants to share with
Bob is actually shared with Bob and not with an imposter acting as Bob.
3. Message Integrity: The other point is that the message which Alice has sent to Bob should reach
Bob without being altered on the way. Payment of Rs.500 shouldn’t become payment of Rs.5000
when it reaches Bob.

There are various cryptographic algorithms and terms needed to understand these key concepts in an
SSL session. We will look at those pieces briefly one by one and then join them together to form the
complete protocol.
Cryptographic Terms

1. Encryption
The process of converting a plaintext message into a ciphertext message (non-readable format)
with the help of secret key is called encryption and converting ciphertext to plaintext is called
decryption. This ciphertext message is meaningless to any eavesdropper without the key for
decryption.

This helps to achieve the confidentiality of the message sent from Alice to Bob. There are two
ways commonly used for encryption: Asymmetric and Symmetric. In asymmetric, two different
keys are used for the process while in symmetric encryption, both parties use the same key.

2. Symmetric Encryption
Here, Alice and Bob both use the same private key to encrypt and decrypt the message and any
eavesdropper without the access to the key, can’t read the original message.
E Secret Key (Plaintext) = Ciphertext
D Secret Key (Ciphertext) = Plaintext

3. Public Key Cryptography/Asymmetric Encryption

This makes use of pair of keys, public key and a private key. Alice would use Bob’s public key to
encrypt the message, which can only be decrypted by Bob’s private key. Even though Bob’s
public key is accessible to everyone, no one except Bob can decrypt the message without the
private key. Hence Alice can be sure that message would only be read by Bob.
E Public Key (Plaintext) = CipherText
D Private Key (CipherText) = Plaintext

4. Key Exchange Algorithms

As we have seen in the description above, the whole secret lies in the private key. So how would
Alice and Bob share the private keys? For symmetric encryption, the private key needs to be
shared between both the communicating parties and, to achieve that, various key exchange
 algorithms have come into the picture, such as Diffie Hellman and RSA. They use public key
cryptography (asymmetric key) to share the secret private key.

Here, the secret key is encrypted by Alice, using Bob’s public key, and sent to Bob. Bob then
decrypts this using his private key and gets the secret key.

5. Digital Certificates

Now, to use Bob’s public key, Alice should be aware of the Bob’s public key. The problem now
is how to discover other’s public key. The solution here is Bob’s digital certificate, which
contains information about him and his public key. When Alice contacts Bob for the first time, the
certificate would be downloaded by Alice’s browser and the browser will extract the public key.

Sample certificate for facebook.com looks like:

 And the public key can be found in the details:

6. PKI/CA

The next problem is to determine that the public key and the certificate belong to the user they
claim to belong to. To solve this problem, the cryptography world has PKI (Public Key
Infrastructure), which is a collection of people, policies, software, and hardware to manage
everything related to digital certificates. They certify the association of a public key with the
domain and its owner. There are various key components such as the Certification Authority
(CA), Validation Authority (VA), Registration Authority (RA), etc., involved in this process.
7. Certification Authority (CA)

CA’s are basically the third-party authorities which are trusted both by Alice and Bob (i.e., by the
owner and the user). CA’s bind the public key to the owner by digitally signing the certificate with
their own private key, saying that “this public key belongs to this owner, in our case Bob.” If the
user (i.e., Alice), trusts the CA and can identify its authentication by its signature, it would trust
Bob with its public key.

For example, if you click on the green lock beside https, you can check that the certificate is
verified by VeriSign, which is a third-party authority.

8. Digital Signature/ Message Integrity

In the last section, I referred to the certificate being digitally signed by CA. How does a digital
signature work? With a digital certificate, we want to be sure of authenticity and message
integrity. This is achieved by a public key crypto algorithm. Let’s consider a scenario where a
website wants to send its “Terms of Use” document to the clients. The purpose here is not the
privacy of the document but authenticity and integrity. The site’s public key is available to all
the clients by its digital certificate. Steps involved would be:
1. Site owner would take a hash of the entire document and this hash is called message
digest.
2. He would encrypt this message digest with his private key. This is called his digital
signature.
Digital Signature = E Private Key (Message Digest)
3. He would then send the document to his clients signed with his digital signature.
4. The clients receive the digital signature of the site along with the document.
5. They would calculate the hash of the document received using the same hashing
algorithm.
 6. Clients would then decrypt the digital signature with the site’s public key. After decryption,
they would get the message digest sent by site owner.
Message Digest = D Public Key (Digital Signature)
7. Clients would then match the hash of the document created by them with the message
digest.
8. And if they match, this ensures that document was received unhampered and the
signature was legitimate.

This ensures authentication as well as message integrity.

Similarly, in the old scenario, when the browser receives Bob’s certificate signed by CA, they will
match the integrity of the certificate and authenticity of the CA by verifying the signature.

SSL Protocol

At the application layer, when Alice queries any HTTPS site, she gets a digital certificate from the site and
a secure communication channel is established. But, at lower layers of TCP/IP stack, there are plenty of
packets travelling between Alice and site to initiate that secure channel.

The SSL handshake plays a crucial role in the complete process by syncing client and server as to the
encryption methods and keys to use for further communication. Let’s look at the detailed SSL
process. Wireshark has been used to capture the packets.

Step 1: Client Hello

The client’s browser sends the website a handshake record with multiple fields as seen below.
As seen, “Client Hello” is the first record sent to the server with the TLS version 1.0 (SSL 3.1). This whole
record is split into multiple different messages: Random, Session ID, Cipher Suites, etc.
Random is the 28-byte random number sent to the server, which will be used later on to compute the
keys.
Session ID, which is currently 0 because we are creating a new session.
Cipher Suites is the list of client supported encryption algorithms sent to the server.

Step 2: Server Hello

Server responds with “Server Hello” handshake record.

Here the server replies with the TLS version and its own 28 random bytes, which will be used in
conjunction with the client’s 28 random bytes later on. The server also creates a new session and sends
the client the session ID for further communication. The server decides on the cipher suite that will be
used for secure communication between them. As we can see, here it is
TLS_RSA_WITH_AES_256_CBC_SHA. RSA is the key exchange algorithm used for digital certificate,
AES_256 is the symmetric key encryption algorithm, CBC is the cipher mode, and SHA is the hashing
algorithm used for message integrity.
Along with the handshake record, the server also sends a certificate record with the issuer and owner
details, the validity of the certificate and the owner’s public key.

Sometimes, even clients need to authenticate themselves to the server with the certificates. In this case,
the server sends a “Server Hello Done” message to the client saying it doesn’t need any certificate.

Step 3: Compute Premaster Secret

Once the client receives the server’s certificate, it authenticates the details and, after the authentication is
successful, the client moves on to the next step. Here, the client generates a 48-byte random number
using a Pseudo Random Generator called premaster secret. This is to be securely communicated to
the server, since this will be further used in the keys generation.
As seen before, the server has picked up “RSA” as the key exchange mechanism and, using RSA, this
premaster secret would be communicated to the server by the client. This premaster secret would be
used to compute master secret and key block. Step 4 and Step 5 describe the computation.

There is another record sent, “Change Cipher Spec,” which indicates that after this, the communication
will be encrypted using the agreed-upon keys and algorithm.

The last record sent by the client in this communication is “Encrypted Handshake Message,” containing
hash and MAC of the previous handshake messages using the SHA hashing algorithm.

Step 4: Compute Master Secret

By now, both sides know the 48-byte premaster secret, the 28-byte client random number and the 28-byte
server random number. Using these values and a pseudo random number generator, both client and
server calculate the 48-byte master secret value.

As per the specification, the 48-byte master secret is calculated as:

master_secret = PRF(pre_master_secret, “master secret”,ClientHello.random + ServerHello.random)

Step 5: Compute Key Block

With the above calculated master secret, both client and server calculate the key block.

As per the specification:

key_block = PRF(SecurityParameters.master_secret,”key expansion”,

SecurityParameters.server_random + SecurityParameters.client_random);

Here, master_secret is the entropy source. This key_block is then divided into different blocks to obtain
different sets of keys, such as a client write MAC secret, a server write MAC secret, a client write
key, a server write key, a client write IV, and a server write IV.
Step 6: Server confirms Encryption

The server tries to decrypt the “Encrypted Message” record sent by client and verifies the hash and MAC.
If it doesn’t match, the SSL handshake fails and the connection is closed.

If the server successfully verifies the encryption, it sends the client a “Change Cipher Spec” record,
saying that “All the messages after this would be encrypted.” Along with this, it also sends Encrypted
Handshake Message.”

The client performs similar verification with the server’s handshake message and, once successful,
proceeds to the last step.

Step 7: Encrypt Application Data

Using the keys calculated above, the client and server initiate a secure communication and data further
sent is encrypted.
This picture shows the overall communication:

References:-

1. Specification : http://tools.ietf.org/html/rfc2246#page-43
2. Public Key Crypto : http://en.wikipedia.org/wiki/Public-key_cryptography
3. PKI : http://en.wikipedia.org/wiki/Public_key_infrastructure
4. SSL : http://en.wikipedia.org/wiki/Secure_Sockets_Layer
On SSL

In this article you will find useful information about SSL, Certificates Chaining and the best tricks about
defeating SSL (with SSL Sniff, SSL Strip, BEAST, THC-SSL-DOS).

What Is SSL and how does it work?

Figure1

The Secure Sockets Layer (SSL) is a protocol used by millions of

websites to protect data as it moves between the user’s computer and
the server the website is hosted on. SSL provides secure
communication between client and server, following three main
goals: Privacy, Integrity and Authentication. To make this possible,
SSL uses : -Encryption – Hiding what is sent from one computer to
another by changing the content using cryptography – based on a
public-Key encryption. -Identification – Making sure the computer
you are speaking is the one you trust.
Originally invented in the 1990s, it has been upgraded many times
and is often referred by its newer name Transport Layer Security
(TLS).

Certificate Chaining
When people think about certificates, they usually think about certificates coming in pairs. Actually instead
of just 2 certificates, there could be more. You can have a certificate chain as there are no standard that
says how many the maximum is.

Let’s see how we verify them:

-Verify that the name of the leaf is the same as the site you’re connecting to

-Verify that the leaf certificate has not expired

-Check the signature

-If the signing CA’s is in our list of trusted root CA’s, STOP. Otherwise move one up the chain, and
repeat.

Figure2

So we can observe the verification is made using a simple recursive function, focused on signature
validation.

The results of a naive attempt at validation is a chain that is complete and nothing more.

Let’s say we have this scenario:

Figure3

What will stop me of doing this ?:

Figure4
Creating another Certificate, for some other website, paypal.com for example, signing it with our leaf
certificate (infosecinstitute.com) and then pass this chain to any client. So, if we go back and look how to
validate, everything will look like normal:

-All signatures are valid;

-Nothings has expired;

-The chain is intact;

-The root CA is embedded in the web browser and trusted.

But we just created a valid certificate for Paypal, and we are not Paypal.

The missing piece is a somewhat obscure field, called basicConstraints.

Figure5

The Basic Constraints idea is that not

all certificates should do everything.
If you have an end entity certificate
to identify a website, that certificate
should be used just to identify your
website. It shouldn’t be used to sign
other certificates, for key revocation
or any other reason.

Back in the day, the problem was that most CA’s (SSL implementations) didn’t bother to check this,
leaving basicConstraints field blank. So anyone with a valid leaf node certificate for a domain could create
and sign a leaf node certificate for any other domain and presented with a complete chain; IE, Outlook,
Konqueror, OpenSSL and others, considered it valid.
SSLSNIFF – A tool for automated MITM attacks on SSL connections

Figure 6
 On the client side:
-Intercept a connection from the client side;

-Generate a certificate for the site it is connecting to;

-Sign it with any random valid leaf node certificate;

-Pass the certificate chain to the client.On server side:

-Make a normal connection to server;

-Pass the data between client and server decrypting and encrypting at each end.

Quick How To:

Setting up iptables

-Flip your machine into ip_forward mode

echo 1 > /proc/sys/net/ipv4/ip_forward

-Add a rule to intercept SSL traffic

iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-ports <$listenPort>

-Run arpspoof

arpspoof -i <eth1> -t <targetIP> <gatewayIP>

SSLSNIFF Post Disclosure

The question becomes: Is this tool still useful? You’d be surprised who still doesn’t check
basicConstraints. Even after the browsers have been patched, this tool is still useful because most people
who get SSL warning dialogues, they ignore them and just click through them.
So it is still useful as a general man-in-the-middle tool for SSL and for deploying other vulnerabilities as
well.

After the latest updates, sslsniff supports modes for hijacking auto-updates from Mozilla products, as well
as for Firefox/Thunderbird add-ons. Attackers can specify payloads of their choice, which will be delivered
to the targets being the man-in-the-middle.

================================================================================
==

Get SSLSNIFF – https://github.com/moxie0/sslsniff

SSL Stripping – The concept of bridges

In the content of web browsing, SSL is almost never encountered directly. Very few people type HTTPS://
when they are going on a webpage, most just use the name of the website directly. The secured protocol
is encountered as result of a 302 redirect form from a http:// url to a https:// url and mostly on links that
users clicks on (shopping, checkout, sign-in, etc…) Both of these points are like bridges between insecure
and secure protocols.

Basically, sslstrip performs a MITM attack on all http connections on the network. Then it watches the
traffic go by and it’s looking for two forms, links and 302 redirects from http:// to https://.

-When finds a https:// link, it swaps it to an identical http:// link and it keeps a map of what is changed.

-When finds a 302 redirect, it looks for the location header, which is where the redirect URL will be, and if
see a https:// link in there, it will swap it for an identical http:// link and keeps a map of what is changed.

Then it will continue to watch http traffic go by and if will see a request for a URL that was stripped, it will
send SSL to the server. So the server will not get something wrong, it’s getting the SSL connection as it
expect but on the client side, it still happens to be HTTP://.

Let’s take a quick look over SSL Strip Features:

-ARP spoofing, the attacker can intercept all network traffic of the target host;

-The attack will turn all HTTPS connections to HTTP instead;

-Meanwhile, the target server will receive a normal HTTPS connection as expected;

-HTTP traffic is transmitted in clear, so an attacker can easily implement sniffing.

Quick How To:

-Enable kernel packet forwarding

echo “1″ > /proc/sys/net/ipv4/ip_forward

-port forwarding, (I will use port 10000 as listening port);

iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port <$listenPort>

-ARP spoofing (get arpspoof from here http://sourceforge.net/projects/arpspoof/files/arpspoof/arpspoof/);

arpspoof -i <eth1> -t <targetIP> <gatewayIP>

-Run sslstrip.

sslstrip.py -l <$listenPort>

================================================================================

Get SSL STRIP – https://github.com/moxie0/sslstrip

Convergence

Back in 2011, after Comodo Company got hacked several times, Moxie figured out what we actually really
need in order to browse securely. He called it Trust Agility, and pointed 2 properties that are the essence
of what’s Certificate Authorities have missed:

-Individual users can decide where to anchor their trust;

-A trust decision can be easily revised at any time.

After creating 2 deadly tools to defeat SSL (SSLSniff and SSLStrip), Moxie Marlinspike came with his
solution for replacing SSL Certificate Authorities, Convergence.

Moxie advertises the project as a way of dispensing with certificate authorities (“An agile, distributed, and
secure strategy for replacing Certificate Authorities“). At the first glance that’s true. You get a Firefox add-
on that, once activated, completely replaces the existing CA infrastructure. Whenever you visit an SSL
site, your browser will talk to two or more remote parties (notaries) and ask them to check the site’s
certificate for you. If they both see the same certificate, you decide to trust the site.

The approach is great in its simplicity: if you can see the same certificate from several different locations
you conclude that it must be the correct certificate.

-Convergence home page – http://convergence.io/index.html

-A complete list of notaries you can choose to trust – https://github.com/moxie0/Convergence/wiki/Notaries

BEAST – Browser Exploit Against SSL/TLS

Description: The SSL protocol encrypts data by using CBC mode with chained initialization vectors. This
allows an attacker, who has gotten access to an HTTPS session via man-in-the-middle (MITM) attacks or
other means, to obtain plain text HTTP headers via a blockwise chosen-boundary attack (BCBA) in
conjunction with JavaScript code that uses the HTML5 WebSocket API, the Java URLConnection API, or
the Silverlight WebClient API. This vulnerability is more commonly referred to as Browser Exploit against
SSL/TLS or “BEAST”.

“BEAST” was debuted at the Ekoparty security conference in Buenos Aires, Argentina.

According to the researchers, the exploit, if used by criminal hackers, could leave highly sensitive
financial, online banking, and ecommerce transaction data exposed to interception and harvesting.

The exploit attack impacts TLS 1.0 and SSL 3.0, but does not work for TLS versions 1.1 and 1.2.

The Beast creators, Duong and Rizzo, created a video that demonstrate the attack

http://www.youtube.com/watch?v=BTqAIDVUvrU

SSL/TLS Renegotiation – Denial of Service

The premise of the attack is simple: “An SSL/TLS handshake requires at least 10 times more
processing power on the server than on the client. The handshake is only performed at the beginning
of a secure connection to establish it. When SSL/TLS Renegotiation is enabled on the server, a user is
allowed to send a renegotiation request which initiates a new handshake. Since it takes much less
resources for a client to perform a handshake, requesting multiple handshakes per second could cause a
denial of service on the server side SSL/TLS interface. Therefore, if a malicious user on one host
requests multiple renegotiation requests it will exhaust the server’s resources and not allow any other
user to establish a connection”.

Check if SSL/TLS Renegotiation is enabled:

# openssl s_client -connect ip:port

R
A few weeks after ietf.org made public this vulnerability, a German hacking group called “The hackers
choice” released a new DDOS tool, presented at DC4420, called TLS/SSL DOS. “This proof of concept
tool exploits a vulnerability in SSL. It can knock of a server off the internet by exhausting its CPU power.
This tool is by far not complete and can be greatly enhanced to further the impact.” they said.

THC-SSL-DOS exploits the renegotiation property of SSL by overloading the server and knocking it off
the Internet.

The tool can be found in 2 versions, binary and source, so it can be used on both, windows and linux.

Download

www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4-win-bin.zip

www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz

Use “./configure; make all install” to build.

Usage:

./thc-ssl-dos 127.3.133.7 443

Handshakes 0 [0.00 h/s], 0 Conn, 0 Err

Secure Renegotiation support: yes

Handshakes 0 [0.00 h/s], 97 Conn, 0 Err

Handshakes 68 [67.39 h/s], 97 Conn, 0 Err

Handshakes 148 [79.91 h/s], 97 Conn, 0 Err

Handshakes 228 [80.32 h/s], 100 Conn, 0 Err

Handshakes 308 [80.62 h/s], 100 Conn, 0 Err

How to defend:

A short time after thc-ssl-dos tool release, Jason Rahm created 20 beautiful code lines under the iRule
name that elegantly defeats the attack. Its premise is simple:

If a client connection attempts to renegotiate more than five times in any 60 second period, that client
connection is silently dropped.
By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time,
fully negating the attack. There should be no false-positives dropped, either, as there are very few valid
use cases for renegotiating more than once a minute.

The iRule

when RULE_INIT {

set static::maxquery 5

set static::seconds 60

when CLIENT_ACCEPTED {

set rand [expr { int(10000000

* rand()) }]

when CLIENTSSL_HANDSHAKE {

set reqno [table incr "reqs$rand"]

table set -subtable “reqrate:$rand” $reqno “ignored” indefinite $static::seconds

if { [table keys -count -subtable "reqrate:$rand"] > $static::maxquery } {

after
5000

drop

}
}

when CLIENT_CLOSED {

table delete reqs$rand

table delete –subtable reqrate:$rand –all

With the iRule in place, you can see its effect within a few seconds of the test restarting.

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Jason also provided a visual workflow to elucidate its mechanics.

Figure 7
As a conclusion, I would like to share Calum MacLeod of Venafi words “Ultimately it is not SSL that’s
broken, but the management of SSL in large enterprises.”

Note: I avoided to talk more about BEAST (“Browser Exploit against SSL/TLS”) in this article, but I will
cover that in my next article.

References:

1. Wikipedia – Secure sockets layer -http://en.wikipedia.org/wiki/Secure_Sockets_Layer

2. IBM – Digital certificate authority (CA) – http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?

topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtps7%2Fs7dca.html

3. Moxie Marlinspike – SSL Sniff http://www.thoughtcrime.org/software/sslsniff/

4. Moxie Marlinspike – SSL Strip http://www.thoughtcrime.org/software/sslstrip/

5. Convergence – http://convergence.io/index.html

6. BEAST – http://vnhacker.blogspot.ro/2011/09/beast.html

7.[TLS] SSL Renegotiation DOS – http://www.ietf.org/mail-archive/web/tls/current/msg07553.html

8. The Hackers Choice – http://www.thc.org/thc-ssl-dos/

9.SSL Renegotiation DOS attack – an iRule Countermeasure – https://devcentral.f5.com/blogs/us/ssl-
renegotiation-dos-attack-ndash-an-irule-countermeasure

SSL Unleashed
In this article, I am going to tell you everything about SSL: What it is, why we need it, its technical and
non-technical aspects, etc. This article covers the introduction, SSL certificate, encryption, the process of
encryption, and how your browser interacts with and trusts that certificate provided by the website you are
visiting.

Existence of SSL

There are basically two aspects of SSL. One is encryption and the second
is identification. Encryption is what you do to hide the content of the data sent from one machine to
another machine. It is done by changing the content of the data so it looks like garbage that is human-
readable but not human-understandable. It is exactly like speaking in a different language with which one
person is not familiar. I am Indian; if someone speaks in the Russian language, it is not understandable
by me, so to me the Russian language is like an encrypted language. However, if I get a translator and
he/she translates that Russian language into Hindi then I can say that now it is understandable by me. So
it is said that message has been decrypted.

Identification is related to trust. In the previous scenario, how can I trust the translator who is converting
Russian language to Hindi? Is she/he legitimate? Can I trust him/her? In the digital world, it is something
like this. Your machine has to trust the SSL certificate (security mechanism) provided by the website via
an SSL certificate issuing vendor.

Encryption Explained

To understand the scenario, let’s take an example directly. Let’s suppose you are sending credit card
details to the company (any company/online purchasing website, etc.)
So here is the scenario: You are on the left and you will be sending your card details to the other
machine. Now there can be two scenarios:

1. Without SSL
2. With SSL

Without SSL: In this scenario there can be another machine in your network that can grab the details
sent by another machine, as shown in the figure below.

As you know, this scenario is without SSL. In this case, any malicious user lying in the same network can
perform an MITM attack or any other attack that contains simple network traffic monitoring and can grab
your credit card number or any other personal details. So it is always necessary to use SSL to act as a
barrier. It creates a tunneling technique.

With SSL: SSL puts the security mechanism on the network layer before you transfer the data. As the
picture below shows, it creates a barrier or tunnel through which the user can transfer any data to the
other network. This time the malicious user (lying on the same network) will see the tunnel, so he won’t be
able to grab your private data as it passes through the tunnel.

As you can in the picture, a malicious user grabs the data passing through the tunnel, but she/he will get
encrypted data, not the real plain text data. So the data can be grabbed but now it has only garbage value
for the cracker/hacker, as she/he will never come to know that what exactly the real data was. In order to
decrypt the data, the hacker will need an encryption key, which she/he will never get.

Let’s see what HTTPS coding looks like. Here I will give you Twitter ‘s sign-in page source code. As you
all know, every sign-in page uses the POST method to pass our data to the server. Every POST method
is defined under the form. A form action method is shown in the picture below.
You can see here that the action in the HTML code is embedded with HTTPS, which is a secure HTTP
method. It confirms that your log-in credentials are secure once you click on the submit button in order to
log in. The actual process of Encryption is enclosed below.

The ‘Actual’ Process of Encryption

Everything we are doing is a digital process that happens in no matter of time but, in reality, it’s really a
long process that has many steps. At each step, integrity and authenticity are involved.

As soon as you hit the button to log in, First it says that now your machine (computer) is ready for the
encryption process. Second, the server will send one certificate to your machine, which has to be digitally
signed by you. If you don’t go through the process of logging in, the server will not send your certificate as
it’s not actually needed, because you are not going to give any credentials to the server. Third, your
machine digitally signs the certificate in the backend and sends it to the server. Indirectly it tells the server
that, “I am ready now, kindly start the encryption process, please.“
Fourth, the server receives the certificate signed by your machine and starts the encryption process at
the client’s end.Last, the server actually encrypts all the messages passed by the client and, after
successful encryption, all the data is passed through the secure tunnel at the server end.

This whole process is called a “handshake.”

The ‘Actual’ Process of Encryption Unleashed in Detail

1. How does your machine choose an encryption process? What are the different
possibilities/methods involved in this process?

Encryption process basically includes three parts.

1. Encrypting Message: There are many algorithms for encrypting messages. The most
famous are AES, 3-DES, and RC4. People generally use one of these methods to
encrypt the message. Each algorithm contains many operations, such as shiftrows,
subbytes, mixcolumns, addroundkey etc.. That is the only strength of these algorithms. If
the algorithm has more operations, it provides better encryption. It is the way of
encrypting data between client and the server.
 2. Hashing—This is known as a message authentication code. This term is used in
cryptography. It includes a hash function combined with a secret key and it is used for
authentication as well as data integrity. The strength of the hashing depends on the
cryptographic function used in that along with the key. GenerallyHMAC-MD5 and HMAC-
SHA1 are used for the hashing.
3. Choosing a Key for Encryption—It contains a key exchange mechanism such as RSA,
DSA, or Diffie-Hellman algorithm. One can get more information on this part by
searching “TLS and public key cryptography” on Wikipedia.

Scenario: Let’s suppose the computer on the left side is about to send the “Hello World” message to the
server and it chooses the AEC cipher method, HMAC-MD5 hashing technique, and RSA key. Along with
all these three data, it also sends the version number of SSL used by your machine for TLS (transport
layer security) and random number. A random number is nothing but the master calculation that is used to
do all other calculation for the encryption process. All this information is passed to the server.

In the next stage, the server sends a certificate to the client. This certificate contains information such as
version number, serial number, signature, issuer, validity, subject, IssuerUniqueIdentifier,
SubjectUniqueIdentifier, Signatu
re algorithm, signature value, public key, etc.

In phase 3, your computer tells the server to start encryption. Here both machines have to take part in the
conversation. There are three steps to accomplish this process.

1. Key Exchange—Here both the machines calculate the master secret code that will be used for the
encryption process.

2. Change Original Text—Your computer tells the server to change the original text written in order to
send the server. In our case, it’s “Hello World.” So the server actually receives confirmation of starting an
encryption process and it starts the encryption process in order to generate the cipher text for our given
text.

3. Finish State—In the last stage of the process, your computer tells the server that all the messages
have been encrypted now and ready to go.

After all these three states occur, the message is sent to the server.
In phase 4, the server receives the messages from the client side and it encrypts those messages to
make it cipher text. Then the server tells the client that it has finished encrypting the message and a
message is sent back to the client is in encrypted form. Both of these scenarios are shown together in the
pic below.

So this is the scenario of SSL. If we take the-real life scenario, then SSL works something like this:
SSL Identification

Another important thing has to be considered while using SSL. It is all about trust. You have to make sure
that the website with which you are corresponding is the real website that you assume it is and that you
trust. It doesn’t mean that, if you have an SSL certificate, then you are secure. Having an SSL certificate
only is not enough, So that is why identification comes into play. It’s all about who you actually trust.

You might have seen the pic below when you try to access a website on the Internet. It represents SSL.
There is a whole big process involved behind this dialogue box. The process behind this is something like
this:
1. First the website that you are going to access through SSL has to go to an organization that
provides certificate authority. That organization will look into the details of the company/website
and it will verify that the information is true about that company.

To get the certificate, the company has to give certain information about itself. That
information may include:

1. The web server name

2. Company name
3. Location of company

Then the authority company checks whether this information is correct or incorrect. If it is
correct, it goes to step 2.

2. That company then creates one certificate and digitally signs it with cryptographic methods
explained previously in this article.

One certificate looks like this (there are different certificates):

The certificate contains this information :

 Signature
 Signature algorithm
 Version
 Serial number
 Algorithm ID
 Issuer
 Identifier for issuer
 Identifier for company
 Public key Information
o Key
Algorithm
 Validity
 Company details
Now the signature is generated. A certificate contains all this information and the numbers used in this
information are taken by the hashing algorithm, which does the calculations and generates signature. So
the only number field that contains all this information is taken by the hashing algorithm in order to
generate the signature. Then that number gets encrypted with the private key, so anyone who is holding a
public key can verify that number.

1. Then they send the certificate to the company that you are going to access. The certificate
generated in step 2 is given back to the company that asked for that certificate. Let’s suppose it
runs an IIS/APACHE/TOMCAT web server. It installs that certificate on the web server. One can
configure any of these web servers to use that certificate.
2. On the other hand, when you are trying to access the website, the certificate comes from the
website at your end. Your browser will verify the details of the certificate and check that the
information is true, then your browser will also sign that certificate. Make sure your browser won’t
sign the incorrect certificate. At the client side, the certificate looks as shown below. This will be
used in the handshake.

3. When your browser gets certificate, it verifies it via the signature and then it encrypts the data.

So I have simplified and unleashed SSL in front of you. Now I will give you a practical demonstration of
how you can generate your own SSL certificate and how to use it.
How to Generate SSL Certificate

We will download and install the required package to install an SSL certificate. Then we will sign the
certificate manually by giving a personal information to the certificate. After this has been completed, we
will restart the HTTPD service in order to run our SSL certificate successfully.

Step 1: Downloading and Installing Required Software

To generate an SSL certificate, OpenSSL and mod_ssl must be installed on the system. This tool may
have already been installed in Apache, however this varies from system to system. So we will install
these tools by using the following command:

# yum install mod_ssl openssl

Figure 1 : mod_ssl Installation process

Step 2: Sign Our SSL Certificate Manually

We will now use OpenSSL to sign our certificate. It is important to have this SSL certificate from a valid
and trusted certificate providing authority if the use is for any company or organization. However, if it’s for
personal use then one can do it at home and there will be no need for a trusted company to provide a
signed certificate.

We will have to follow the steps below to create a self-signed certificate:

 Create A Private Key

Figure 2 : Generate Private Key

 CSR Generation

Figure 3 : Certificate Generation

 Key Generation (Self-Signed)

Figure 4 : Key Generation

 Put Files In Proper Location

Now that we have configured our task and put files into the right folder, we will update the Apache
server by updating the SSL configuration file, which is ssl.conf. We will use the nano editor to update
our ssl.conf file andchange the path of the key file, where we have stored our files, such as the
certificate and key.
The next step is to save and exit this file, after which we will start HTTPD service by typing the following
command in the terminal:

# /etc/init.d/httpd restart

Now that we have set up our secure socket layer, if we attempt to log in to our the server machine
through the client machine or attacking machine via the https protocol, it will ask for the authentication.
Before the authentication, a dialogue box is shown that warns the “connection is not trusted” and asks if
they want to see the certificate that is going to be downloaded to the machine or if they want to stay in
offline mode.
Once the user clicks on the view certificate, it will display the certificate that was created earlier. This
screenshot below illustrates this step:
 Figure 6 : Showing our self generated certificate digitally signed by us

It shows the issuer’s name, organization name, and validity of the certificate. With this secure connection,
if one logs in into the website or network, it will encrypt the plain text data and an attacker won’t be able to
capture it straight away with the Wireshark option.

Experiment: I have set up the Apache server and I have performed an MITM attack in which I pass log-in
credentials without SSL and with SSL. For both ways I captured Wireshark screenshots. Those
screenshots are as follows:
 Figure 7: Authentication Credentials have been captured in plaintext – WITHOUT SSL

As you can see, one can capture your log-in credentials if you are not using SSL and not encrypting your
data.
 Figure 8 : SSL Handshake is Being Done

The SSL handshake is being done now in the next picture; you will see the cipher text being generated
and passing through the network.

As you can see here, the credentials are encrypted now. No one can see the real credentials of the client
passing through the network. Thus we see how SSL is useful to encrypt the data.

 Conclusion

SSL can give protection against man-in-the-middle attacks. It can protect sensitive data such as
log-in credentials, credit card details, home address, phone number, etc.

 References

1. http://pubs.vmware.com/view-51/index.jsp?topic=%2Fcom.vmware.view.installation.doc
%2FGUID-B238BB47-D710-4DAB-945F-B54D46164FE0.html
2. http://validationcertificateinfo.blogspot.co.uk/2012/12/the-advantages-and-disadvantages-
of.html
3. http://uk.godaddy.com/ssl/ssl-certificates.aspx
4. http://en.wikipedia.org/wiki/Transport_Layer_Security
5. https://developer.mozilla.org/en-US/docs/NSS
6. http://tools.ietf.org/html/rfc6101
Transport Level Security – Part 1
This is a non-technical guide which will make you familiar with the transport layer. The main purpose of
writing this guide is to point out why we need major security implementation on the transport layer. What if
the components of this layer get compromised?

Introduction

In today’s digital world, nearly every business has a website. Both tiny companies and huge corporations
have websites. Clearly, the number of individuals and companies who are accessing the internet has
rapidly increased. As businesses around the globe are rapidly increasing, they want the internet to act as
web e-commerce for their business to manage everything centrally.

However, over the years we’re watching that web services across the internet are vulnerable in various
ways. No business wants to put themselves into a vulnerable environment. As a result, the need for
security in the corporate world is also in demand.

If we talk about web applications and services, then it’s a very broad topic. As I mentioned, we are going
to discuss security only for components which are related to the transport layer.

Security Deliberation in Web

The web is simply a client and server system, running on the internet using TCP/IP. There are a number
of security auditing tools and mechanisms which address network security considerations, but there are
many new vulnerabilities which are not appreciated by those tools and mechanisms yet.

Unlike traditional publishing environments, internet is two way, between clients and servers. Attacks can
be done on client applications as well as a web servers. Web servers are at the heart of the corporate
world where a lot of general and sensitive information is stored. If those web servers are compromised,
then reputation and the money of that organization can be lost in no time.

Web browsers are easy to use, and web servers are very easy to configure and manage. That’s how we
produce mass digital information.

The table below shows the security threats we are facing and have faced up to now. There are two types
of threats, passive threats and active threats.
 Category Threat Impact of Threat Mitigation

False information being

Passing Invalid accepted & Attacker may get
Use Cryptography
Authentication DataImpersonate Valid access
Mechanism
user Access of personal data
behalf of legitimate user

Trojan in browser
User data modification Compromisation of machine Use Cryptography
Integrity
Message modification in Information loss Checksums
network traffic
Flood server with bogus Legitimate users cannot
requests work due to long waiting
Denial of IPS/IDS, Honeypot,
Filling server memory state
Service Firewalls
DNS attack for machine The server breaks down
isolation completely
MITM attack Web proxies,
Confidentiality Information Theft from Privacy loss Encryption
server & client techniques
Passive threats: Includes man in the middle attacks between servers and clients on network traffic in
order to gain access to information that’s being shared between them. Generally the information which
attacker gains by doing this is restricted except between that client and server.

Active threats: A attacker could impersonate a user, network, or website in order to gain information
which is usually restricted.

Apart from these two categories, we can also categorize web threats in the way they behave between
clients and servers such as web browsers, web servers and network traffic.

Security Approaches in Web Traffic

There are a number of security approaches available to address each type of web threat. There are some
common mitigation techniques for addressing more than one threat. In network security, strategies differ
depending on location. We have to see first where the service is placed within the TCP/IP stack, in order
to provide mitigation of an attack.

There are three levels that play important roles in network security- network level, transport level and
application level. The figure below illustrates the network level.
Fig:1 Network Level

One way to provide security is to use IPSec policy, which is referred to as an IP security mechanism. The
main benefit of using IPSec is that it’s transparent to end users. It’s a general purpose mechanism to
provide end-to-end security for end users. One of the biggest advantages is it uses a filtering mechanism
that allows only selected traffic to pass. To learn about how to apply IPSec between two Windows XP
clients, click on this link.

Now, onto the transport level. The figure below illustrates the transport level and where we should
implement security in it.

Fig:2 Transport Level

Another general purpose solution to address network security is to implement SSL (Secure Socket Layer)
just above TCP. It’s also referred to as TLS, or transport layer security. There are two implementations of
SSL.

1. SSL can be provided as underlying protocol and can be separated. So it becomes

transparent to a specific application.
2. SSL can be embedded in some packages like web browsers such as Firefox, IE, Chrome. So
if a server wants to use it, those browsers are always up for that. Otherwise it’ll serve as
normal HTTP.

Now, we’ll move on to the application level. To understand the scenario, here’s the architecture for
application level.

Application level security approaches vary with different applications used. That’s why it needs to give
more flexibility to choose a security policy according to the application’s requirements.

Now, we have seen where exactly we can implement security mechanisms in between different layers. In
part two of this series, I will unleash SSL and describe what roles it plays in TLS and how. Stay tuned.

References

http://en.wikipedia.org/wiki/Network_security
http://ix.cs.uoregon.edu/~butler/teaching/11W/cis533/slides/cis533-authentication.pdf
http://www.draytek.co.uk/products/network_threats.html
www.andrew.cmu.edu/course/95-752/notes/netsec.ppt?
http://en.wikipedia.org/wiki/Network_Interface_Layer_Security
http://tools.ietf.org/html/rfc5246
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_overview.html
Download & Resources
Transport Level Security – Part 2 – SSL
Introduction

I’ve already discussed SSL in my previous article. Here I’ll be explaining SSLv3. It was developed by
Netscape.

General SSL Architecture

It was designed to secure end-to-end services on the internet. I’ll show that SSL isn’t a single handed
protocol. It’s a layer of more than one protocol such as:

1. SSL record protocol

2. SSL handshake protocol
3. SSL change cipher spec protocol
4. SSL alert protocol

The SSL record protocol provides basic security to other higher level protocols, specially HTTP, which is
responsible for server client interaction on the web. The other three protocols are responsible for
managing for the whole SSL exchange. There are two basic concepts in SSL. They are:

1. SSL connection : In SSL, mechanism connections are a P2P (Peer-to-peer) relationship.

2. SSL session : Its client-server association. Most likely created by the SSL handshake
protocol.

SSL Record Protocol

It provides two main services for SSL:

 1. Integrity : Handshake protocol, which produces a shared secret key, used to form the MAC
(Message Authentication Code).
2. Confidentiality : Handshake protocol produces a shared secret key to encrypt the SSL
payload.

The chart below describes the operation of the protocol.

The record protocol takes application data and fragments data into blocks. Then it compresses and
adds a MAC to encrypt the data. Finally header information added and transmitted to the TCP
segment. Fragmentation application data is fragmented into blocks of 214 bytes or less. Then
the compression it applies has to be lossless. It shouldn’t increase the content length more than 1024
bytes. Compression is optional. SSLv3 doesn’t use any compression mechanism. After that, the MAC is
computed in which a shared secret key is used. The SSLv3 MAC algorithm is based on HMAC, which you
may find in RFC 2104. The latest version of HMAC uses XOR. Then, it’s time for encryption. It may
increase the content length more than 1024, but the total length of it should not exceed 214+2048.
The following table shows encryption algorithms and their key sizes.
Algorithm Key Size
RC4-40 40
RC4-128 128
AES 128,256
Fortezza (Used in Smartcard
80
Encryption)
IDEA 128
RC2-40 40
3DES 168
DES-40 40
DES 56
The final step of the SSL Record protocol is to add header information to the final encrypted content.

Change Cipher Spec Protocol

Change cipher spec protocol uses the SSL record protocol. It helps the party to avoid a pipeline stall. It’s
a TLS protocol. It consists of one single message of one byte. It causes a pending state in order to copy it
to the current state. It updates the encrypted text to be used in TLS.

The architecture of SSL record:

SSL Alert Protocol

It’s usually used to send and receive SSL related alerts to end to end identities. These alert messages are
also compressed and encrypted. The figure below shows the alert protocol structure.

Each message uses two bytes. The level byte is a value warning and the alert byte conveys the severity
of the payload. If the level becomes fatal, SSL will directly initiates a connection. If there are more
connections in same session, then they may continue. The alert byte contains code which produces a
specific alert. Some alerts are listed below and they can be identified by their name.

1. bad_certificate
2. unsupported_certificate
3. certificate_revoked
4. illegal_parameter
5. decompression_failure
6. bad_record_mac
7. handshake_failure
8. no_certificate
9. certificate_expired

SSL Handshake Protocol

The most important and complicated part of SSL is the SSL handshake protocol. This protocol allows
both ends to connect each other, authenticating each other, negotiating encryption and exchanging
packets. It contains a series of messages transferred between a server and client.

The SSL handshake has four main phases.

Phase 1. Establishing Connection and Capabilities For Security

It initiates the logical connection between a client and a server. It also generates security capabilities
of which a server and a client will both use.
RN are random numbers which are generated by clients. It consists of a 32 bit timestamp and 28
bytes. First, the client sends a client_hello message and waits for the server to reply. The server
replies to the client with aserver_hello message. Both messages contain the same parameters such
as versions, session IDs, cipher suites, compression methods, and initial random numbers. Then, a
random field is generated by the server which is different than the client’s. The cipher suite contains a
single cipher which is selected by the server. The compression field contains the compression
method selected by the server.

Phase 2. Key Exchange & Server Authentication

The server sends a certificate to a client which needs to be authenticated. It contains one or more
chains of X.509 certificates. Then, the server_key_exchange message may be sent if it’s required. It’s
necessary if you use anonymous Diffie-Hellman, ephemeral Diffie-Hellman, RSA key exchange or
Fortezza.

Phase 3. Key Exchange & Client Authentication

After the server sends a certificate to a client, the client should verify whether it’s valid or not. If
everything is satisfactory, then the client sends more than one message back to the server. If there is
no suitable certificate, The client sends a no_certificate alert to the server. Then the client sends a
client_key_exchange_message.
In this phase a client sends a certificate_verify message to the server. This certificate always has
signing capability. It signs a hash code based on the previous message. Verification needs to be
done by signing a certificate. If anyone misuses it, then they won’t able to send that message.

Phase 4. Finish Phase

The fourth phase creates a secure connection. The client sends a change_cipher_spec message.
Then, the client copies the new cipher_spec into the current cipher_spec. Then, the client sends a
finish message. Only the finish message verifies that the key authentication and exchanging of the
key have been successful.

In a nutshell, the whole SSL process can be illustrated as shown in the figure below.
Conclusion

In this article I tried to simplify and describe SSL, it’s architecture and how the SSL handshake works. I
also mentioned the encryption algorithms that are used in SSLv3. In my next article I will present
Transport Layer Security.

References

 http://i.technet.microsoft.com/dynimg/IC197613.gif
 http://technet.microsoft.com/en-us/library/Cc767139.f14-4_big%28l=en-us%29.gif
 http://en.kryptotel.net/images/sslprocess.jpg
 http://www.hit.bme.hu/~buttyan/courses/BMEVIHI4372/ssl.pdf
 http://www.pierobon.org/ssl/ch2/record.htm
 http://www.pierobon.org/ssl/ch2/hand.htm
 http://www.pierobon.org/ssl/ch2/alert.htm
 http://pic.dhe.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-
ztpfdf.doc_put.cur%2Fgtps5%2Fs5hand.html
 http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html
SSL ATTACKS

In the last few years, we have witnessed a wide range of attacks on the SSL/TLS mechanism. In this
article, we will try to cover various attacks that were prominent in the field of cryptography. Transport layer
security (TLS) ensures integrity of data transmitted between two parties (server and client) and also
provides strong authentication for both parties. The attacks launched in the last few years have exploited
various features in the TLS mechanism. We are going to discuss these attacks one by one.

Browser Exploit Against SSL/TLS Attack (BEAST)

This attack was revealed at the Ekoparty Security Conference in 2011. BEAST is based on a type of
cryptographic attack called the “chosen plain text attack.” Before I jump into explaining the details of this
attack, let us take a look at some of the basic concepts to be understood.

Background Information

There are two types of encryption schemes:

1. Symmetric key encryption: Encryption and decryption keys are the same.
2. Asymmetric key encryption: Encryption and decryption keys are not the same.

Symmetric-key encryption can use either stream ciphers or block ciphers. A stream cipher encrypts
one bit at a time, while a block cipher encrypts plaintext in chunks. Let’s talk about block cipher. How is a
message encrypted using block cipher? You don’t use the block cipher on the message directly but
instead you first need to choose the “mode of operation.” CBC (cipher block chaining) is one such mode
used by the block ciphers.

In CBC mode, to make each message unique, an initialization vector (IV) is used in the first block. An IV
is a random string that is XORed with the plaintext message prior to encryption. Each block of plaintext is
XORed with the previous cipher text block before being encrypted. In other words, each cipher text block
depends on all plaintext blocks processed up to that point as shown in the figure below. It’s important to
note that here IV is not a secret; it only adds randomness to the output. IV is sent along with the message
in clear text format. With this background information, let us know focus on how the BEAST attack is
accomplished.
How Is the Attack Accomplished?

It was noticed that TLS 1.0, when dealing with multiple packets, allows the following packets to use an IV
that is the last cipher text block of the previous packet. In other words, an attacker who can see the
encrypted traffic can note the IV used for session cookie (Why? Because the cookie’s location is
predictable). Simply put, an active attacker will be able to gather the IVs for each record just by sniffing
the network. So if the attacker can “guess” a plaintext message, he can make a guess at the session
cookie and see if the cipher text matches. [Note that, since this is a MITM attack, the attacker can mix his
traffic with the victim traffic to see the results].

Practical Example

Now let us consider the message: JSESSIONID=Gxs36NepewqeMI763Hej31pkl.

This is a plaintext and will have to be XORed with the IV (which is cipher text of the previous block). The
attacker has this IV value in his hands. Now if he can “predict” this plaintext value and XOR with IV, he
can check whether it corresponds to the cipher text value. Understandably, it’s not easy to predict such a
random value, but he can guess it a single character at a time. For example “JSESSIONID=G” can be
guessed by trying different characters. Once the first character is recovered, he can shift the attack to the
next character. This way he can guess one character at a time and accomplish the attack. This attack is
not so straightforward and has some limitations:

1. The attacker has to be in the same network and play a MITM attack.
2. The attacker has to modify the traffic to see if the results match; as a result, multiple requests
have to be sent in this process.
3. The attacker can guess only one block at a time.
Solution

This is a vulnerability in block ciphers that use the CBC mode of operation. It was identified in TLS 1.0.
However it was addressed in TLS 1.1 and TLS 1.2 by the use of “explicit IVs” for each block. Hence, TLS
1.1 and TLS 1.2 are not exposed to this attack. Some of the browsers have attempted to implement a
solution to address the vulnerability while still remaining compatible with the SSL 3.0/TLS 1.0 protocol.
Apple’s Safari, even though it has released a mitigation, has chosen to keep it disabled by default.

Google: Update to Chrome 16 or later.

Microsoft: Apply the patch MS12-006.

Mozilla: Update to Firefox 10 or later.

SSL Renegotiation Attack

A vulnerability was discovered in the SSL renegotiation procedure that allows an attacker to inject
plaintext into the victim’s requests. For instance, it allows an attacker who can hijack an HTTPS
connection to add their own requests to the conversation the client has with the web server. Note that the
attacker cannot decrypt the client-server communication.

Background Information

SSL renegotiation is helpful when the routine SSL session is already established and the client
authentication has to take place. For example, say you are browsing an online shopping site which uses
SSL, i.e., HTTPS. Initially, you browse through the site anonymously, add items to the cart, etc. But when
you decide to purchase you will be asked to log in to the site, so now the SSL connection needs to be
adjusted to allow the authentication. Whatever information is gathered prior to this authentication (e.g.,
items added to the cart) has to be maintained even after the authentication. So the new SSL session that
has to be established uses the already existing connection. Note that renegotiation can be requested
either by the client or by the server at any time. For the client to request renegotiation the client sends a
“Client Hello” message in the already-established encrypted channel and the server responds with a
“Server Hello” and then the negotiation follows the normal handshake process. The server can initiate the
renegotiation by sending the client a “Hello Request” message. When the client receives the request, the
client sends the “Client Hello” message and the handshake process takes place. This explains the basic
SSL renegotiation process.

How Is the Attack Accomplished?

Using the renegotiation attack, an attacker can inject commands into an HTTPS session, downgrade a
HTTPS connection to a HTTP connection, inject custom responses, perform denial of service, etc. That
explains to some extent how serious the problem is. It is easier to understand how the attack is
accomplished through the following example.
Practical Example

The action corresponding to each of the numbers present in the below figure are explained in the order
below:

1. Assume that a client wants to connect to a online banking site. He initiates the routine TLS
handshake process
2. The client blocks the request and holds the packets.
3. The attacker initiates a new session and completes a full TLS handshake.
4. The attacker sends a GET request (asking to send money to his account) to the bank application.
5. Server asks for renegotiation.
6. The TLS handshake initiated at step 1 and blocked by the attacker will now be forwarded to the
server, which a new TLS handshake over the previously established encrypted TLS session 2. So
the client now is authenticated and has a valid cookie.
7. Due to this renegotiation, the server now assumes that the previously sent request in step 4 was
actually sent by the client. Hence the request which goes to the server is as follows; it will be
interpreted by the server as a legitimate request and then executed.
 GET /bank/sendmoney.asp?acct=attacker&amount=100000

Ignore the rest: GET /ebanking

Cookie: validcookie

Solution

One way to fix the renegotiation vulnerability for SSLv3 is to completely disable renegotiation on the
server side. As a permanent fix for the vulnerability, a renegotiation indication extension was proposed for
TLS that will require the client and server to include and verify information about previous handshakes in
any renegotiation handshakes.
SSL ATTACKS: Part 2

In the first part of SSL attacks, we have seen details about two attacks, namely BEAST (browser exploit
against SSL/TLS attack) and SSL renegotiation attack. In this second part, we are going to deal with
CRIME, TIME, and Lucky13 attacks. Let us proceed further and try to understand each of these attacks in
detail.

Compression Ratio Info-leak Made Easy Attack

This is a side-channel attack on SSL/TLS that can be used to predict sensitive information, such as the
session tokens, etc. This is done based on the compressed size of the requests. This attack is known to
work against SSL compression and SPDY, which use deflate/gzip data compression techniques. SPDY is
not widely used, but SSL compression is one technique which is very much in use.

Background Information

Before we see the details of the actual attack, let me explain a few things about “compression.” Web
pages are generally compressed before the responses are sent out (this is called HTTP compression),
primarily to make efficient use of available bandwidth and to provide greater transmission speeds. With
compressed data, we can send the same amount of data to the destination but using fewer bits. The
browser usually tells the server (through “accept-encoding” header), what compression methods it
supports and the server accordingly compresses the content and sends it across. If the browser does not
support any compression, then the response is not compressed. The most commonly used compression
algorithms are gzip and deflate.

Accept-Encoding: gzip, deflate

When the content arrives, it is uncompressed by the browser and processed. So, basically with SSL-
enabled web sites, the content is first compressed, then encrypted and sent. But you can determine the
length of this compressed content even when it’s wrapped by SSL.

How Is the Attack Accomplished?

A CRIME attack is based on observing how the compressed length changes for different input values.
Initially the attacker observes the size of cipher text sent by the browser and then makes multiple
requests to the target website to observe the compressed response sizes. The attack primarily works by
taking leverage of the “compressed size” of the text when there are repetitive terms. The attack can be
best understood by following the below example, which demonstrates how an attacker can exploit it in
real time.

Practical Example
Consider the below POST request made by a valid user.

Request:

POST / HTTP /1.1

Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

As mentioned earlier, this content is first compressed and then encrypted and sent. But note that the size
of this encrypted piece can still be found out just by sniffing the network traffic. Now the attacker’s target
is to get the value of “secretcookie.” The attacker now can make the victim click on a link and, using
JavaScript, he can trigger the below request.

Request triggered by the attacker:

POST /secretcookie =0 HTTP /1.1

Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

In the above request, “secretcookie =0″ is the attacker-controlled input. When repetitive terms are
encountered during the compression, instead of displaying it a second time the compressor says “This
text is found 67 characters ago.” So this reduces the overall size of the compressed output. In the above
request, since the word “secretcookie” is repeated, the compression is done accordingly by taking note of

POST /secretcookie =0….

POST /secretcookie =1…
POST /secretcookie =2…
POST /secretcookie =3…
POST /secretcookie =4…
POST /secretcookie =5…

Now can you guess which POST request would be best compressed, i.e., which POST request would
have the smallest compressed size? The one with “secretcookie =5″ would compress the best. This is
because it has more repetitive characters. In other words, “secretcookie =5″ is repeated twice and hence
the compressed size is less. Thus the attacker can confirm that 5 is the first character of the secretcookie.
Going ahead with this logic, he can brute-force the other characters as well and extract the entire cookie
value.

Solution:

CRIME can be remediated by preventing the use of compression at the server end. It can also be
prevented at the client end by disabling the compression of HTTPS requests. This is because, in TLS 1.2,
the client sends the server a list of compression algorithms that are supported by it and the server picks
one of them. If the client sends no compression algorithm, then the data cannot be compressed.

Timing Info-leak Made Easy Attack

In spite of being a very interesting attack, CRIME majorly suffers from two drawbacks:

1. The attacker must be the man in the middle (to be able to read the messages) and he must
also control the plaintext (which is sent as input to the application).
2. CRIME was very soon mitigated by disabling the TLS compression.

The TIME attack overcomes both of these problems. So this attack doesn’t need an attacker to sniff the
network. Instead of focusing on the HTTP request, it focuses on the HTTPS responses. To explain this
attack in simple terms, all an attacker needs to do is redirect a user to a malicious website that will run
some JavaScript to get the encrypted secret data.

Background information

The basic concept here is that, in order to find out if there is difference in the length of two messages, we
can observer the time it takes to send these messages across the network. The larger the difference, the
more time it’s going to take.

How Is the Attack Accomplished?

The basic goal of the attacker is to force the length of compressed data to overflow into an additional TCP
packet. The attacker then pads the remaining data. When the maximum size is crossed, any additional
packet created (due to wrong guess), introduces an additional full round trip with a significant delay.
Consider a simple user input (say “secret = data”). Assume that the value is reflected in the response
along with the “secret.” In other words, whatever the user inputs is reflected in the response. Let us say in
the first request, the user sends “secret = anything” and receives a response with a size of 1024 bytes. If
the user input is “secret=a” in the second request, the response size will be less and hence it will take
less time to reach than the first request. Likewise, it is possible to predict the every character in every
position of our payload by observing the response times (to be precise by observing the “shortest
response times”). This attack is little difficult to comprehend and so I have mentioned a video link here
which could give you a better insight for the folks who are interested.
Black hat video link: http://www.youtube.com/watch?v=rTIpFfTp3-w&noredirect=1

Solution

Including CSRF, CAPTCHA tokens in the request could avoid the multiple requests that an attacker
makes using the JavaScript. Adding random timing delays to the decryption for any timing attack can be
reasonable to disrupt this attack, but it may not be completely helpful. The application should take care of
the reflection of user input in the response.

Invalid SSL Certification Exploitation

Introduction

Internet usage is growing dramatically, but the vast majority of Internet users don’t have any security
backgrounds. Nor do a large majority of companies care about information security, and the severity of
any attack could harm the valuable assets of these companies. They don’t give their employees security
awareness sessions, either. For these reasons, humans are the weakest link in the information security
chain.

In this article we will talk about SSL protocol and SSL certificates, which will help webmasters make sure
that users’ information travels safely through the Internet in a secure manner. Moreover we will talk about
invalid SSL certificates which could lead to stealing users’ credentials or stealing sensitive information
which could be used in further attacks.

SSL protocol is in widespread use in applications such as Web browsing, electronic mail, Internet faxing,
instant messaging and voice-over-IP (VoIP).

Information Security Principles

As we know, the main practice of information security is to defend information from unauthorized access,
disclosure, disruption, modification, recording or destruction. Moreover, the major role of the information
security engineer is to find, track and manage risks of our asset, which could be a server, network or/and
people. The impact of these risks could affect the confidentiality, integrity or availability of this asset, so
these three (CIA triad) are the core principles of information security.

What is SSL?
SSL is the acronym for Secure Sockets Layer; it is a cryptographic protocol which is specially designed
for providing secure channels for communication over the Internet. SSL usage is for assuring whom
clients are talking with. In other words, SSL is used for verifying the identity of the remote server. For
example, if you are talking tohttps://www.example.com and the SSL certificate for example.com is valid, it
means that you are talking to the real server.

Why Use SSL?

As we mentioned earlier, Webmasters, Web application developers and administrators usually use SSL
protocol for making sure that user information travels safely through the Internet in a secure manner. This
helps prevent an evil-intentioned attacker or script kiddy from sniffing the network to steal confidential
information like users’ credentials, which an attacker could use later for accessing the same application or
using the username and password combination to try to figure out the credentials of the same user on any
other application. The vast majority of users always use the same username and the same password
combination as a credential for logging to other applications, for example the credentials that the user
uses to login to Facebook will be the same credentials that the user uses to login to his Gmail account, or
he may slightly change the password by appending some numbers or special characters to the password,
which also will be an easy task to guess the password by using hybrid attack (appending numbers and
special characters to the dictionary words).

SSL is a cryptographic protocol. SSL provides data confidentiality by creating a secure channel for
communication over the Internet for transferring the data confidentially. Moreover, SSL provides data
integrity because the SSL certificates must be signed by a third party called Certificate Authority, so the
attacker can’t sign the fake certificate by itself, and if the attacker uses a certificate of another entity to
fool the victim, the browser will warn the user that the website uses an invalid certificate (someone else’s
certificate), which is a clear clue that someone is trying to attack him.

How SSL Protocol Works

SSL is initialized at layer 5 (the session layer) then works at layer 6 (the presentation layer) as the
following:

1. The session layer during a handshake using an asymmetric cipher in order to negotiate cipher
settings and determine a shared key for that session.
2. The presentation layer uses a symmetric cipher and the shared key to encrypt the rest of the
communication.

Invalid SSL Certificate Reasons

There are many reasons for an SSL certificate to become invalid. Some of these reasons might be the
following:

Revoked certificate:

o Certificate or its signature is revoked.

o Failure to check the revocation status.
 Fake certificate:
o The certificate is subscribed illegally.
 Certificate chain is broken:
o The chain consists of one self-signed certificate.
o The chain does not end with a trusted root certificate.
o The chain contains certificates which are not meant to sign other certificates.
o Root or intermediate certificate has expired or its time has not come yet.
o The chain was not built.
 The domain specified in the certificate does not match the website to which connection is
established.
 Certificate time violation:
o Action time has expired.
o Action time has not come yet.

 Certificate structure is broken:

o The structure is damaged.
 Signature checking error.

If you are surfing a website which usually uses a valid SSL certificate and the browser shows that the
website uses an invalid SSL certificate, it’s highly recommended to not continue working with the website,
because it may be a clue that someone is attacking you.

Why is it Dangerous to Use an Invalid SSL Certificate?

Nowadays some webmasters are using invalid SSL certificates to create a secure communication
channel between the server and the application users. They think it’ll provide the same security posture
as a valid SSL certificate, which is not the case, because using an invalid SSL certificate will put the
application users in a huge risk, the same risk as sending users’ credentials through clear communication
channels because any evil-intentioned attacker can sniff the credentials and session ID for the application
users.

Demonstration for Exploiting an Invalid SSL Certificate

Now we are going to demonstrate how an attacker can exploit this vulnerability. We will use the Cain &
Abel tool for exploiting it. According to the official website, Cain & Abel is a password recovery tool for
Microsoft Operating Systems. It allows easy recovery of various kinds of passwords by sniffing the
network, cracking encrypted passwords using Dictionary, Brute-Force and Cryptanalysis attacks,
recording VoIP conversations, decoding scrambled passwords, recovering wireless network keys,
revealing password boxes, uncovering cached passwords, and analyzing routing protocols.

The latest version is faster and contains a lot of new features like APR (ARP Poison Routing),

which enables sniffing on switched LANs and Man-in-the-Middle attacks. The sniffer in this

version can also analyze encrypted protocols such as SSH-1 and HTTPS, and contains filters

to capture credentials from a wide range of authentication mechanisms. For more information, please visit
the official website of Cain & Abel, mentioned in the references section at the end of this article.

An attacker will exploit this vulnerability using the following scenario:

1. The attacker and the victim must be residing in the same physical network segment.
2. The attacker will install and run Cain software.
3. The attacker will perform ARP poisoning to sniff the network traffic between the victim and the
gateway.
4. The victim tries to access a web application which uses an invalid SSL certificate.
5. Cain will send the victim an invalid SSL certificate which belongs to Cain.
6. The browser will inform the victim that the SSL certificate is invalid.
7. Once the user adds an exception for accepting this certificate, the attacker can capture the victim
credentials and session identifiers and any other activities as a clear text.
8. The attacker can use a network traffic analyzer tool such as Wireshark to filter the traffic searching
for the victim’s application requests, and then the attacker can extract the cookies and referrer
parameters from the request. In addition, Cain itself stores all HTTPS traffic as a text file format
that has the whole conversation between the client and the server in a folder called HTTPS inside
the Cain folder, seen in the screenshot below.
Conclusion

Most webmasters are using an invalid SSL certificate, which is a dangerous issue because it could lead to
impersonating application users by stealing users’ credentials and session cookies information. To solve
this issue, the SSL certificate must be signed by a valid certificate from a trusted CA like VeriSign.

References

http://en.wikipedia.org/wiki/Information_security#Basic_principles

http://en.wikipedia.org/wiki/Secure_Sockets_Layer

http://www.oxid.it

http://support.kaspersky.com/us/8466
How to Remote Access the Secure Way
Businesses in all industries often need to provide their employees with a way to access their internal
networks when they’re away from the office. Such functionality is especially important when employees
travel for business, and to assure continuity if a disaster strikes a work site. Remote access is also useful
for technical support that’s provided by an off-site party.

It’s vital to keep internal networks secure, for a multitude of reasons. Some industries deal with highly
sensitive data, such as finance and medicine. But the confidentiality and availability of corporate data is
vital, regardless of industry. Internal network security is easy to overlook until there’s an attack. After an
attack, a company can lose an awful lot of money when equipment is harmed and data is stolen. Network
attacks can also make a company subject to litigation and reputation damage. For example, consider the
payment system attacks that have happened to a few major retailers recently. However expensive it is to
properly secure a network in the first place, there’s always a significant return on investment in the long
run.

Nothing can ever be made invincibly secure, but there are a number of ways to provide remote access in
a reasonably secure way.

Over the past dozen or so years, many remoting applications have grown in popularity. Some of them
have been widely deployed for corporate use. Which application you choose will depend on your budget,
what kind of computers you have in your local network, which operating systems they run, the number of
employees who will have remote access, and what kind of technology they have at home and while
traveling. It’s also vital to consider corporate policies related to IT and the management of data.

Here’s a comparison of a few of the remote access applications I recommend.

TeamViewer

TeamViewer is an excellent choice if you’d like online meeting functionality in addition to remote access.

The online meeting features include support for video conferencing and VoIP. Most notebook PCs and
newer models of smartphones and tablets have front-facing video cameras these days. So, if you’d like to
take advantage of the video conferencing feature, chances are your employees have their own
compatible devices to use when they’re away from the office.

TeamViewer can be installed in Windows, OS X, some of the more popular GNU/Linux distros, iOS,
Android andWindows Phone 8. So, there’s a lot of platform flexibility both on the desktop end and the
mobile end.

If an employee may be using different PCs while they’re away, it’s possible to install a TeamViewer client
on a USB stick, which can have their personal configurations on it.
Only buy the Business license if you’re only going to set up remote access on a few computers. The
Premium license is good if you’ll be remoting from a large number of computers, and any individual
computer being remoted to will only have one session at a time. If you need the ability to have up to three
devices remoting to the same PC similtaneously, you’ll need to purchase the Corporate license. Like the
other remoting applications I mention here, TeamViewer offers a free trial. I highly recommend installing
the free trial first. Then, you can try TeamViewer in your network and see if it’s a good fit, according to
your needs and what sort of technical configuration you have.

Good encryption standards for remote sessions are a must. Remote sessions are often an attractive
target for blackhats, as cracking into one can give them access to your corporate network. All versions of
TeamViewer support VPN. If your network doesn’t have a heavily secured WAN (wide area network)
connection, you will need to deploy VPNs for a reasonable level of security. I will get into the security
considerations for VPNs later in this article. TeamViewer encrypts sessions with 256-bit AES. 256-bit keys
are good for that purpose, and I wouldn’t use a remoting application that uses encryption standards with
keys that are any shorter.

TeamViewer can be downloaded from their website, http://www.teamviewer.com.

RealVNC

Of all of the remoting applications in the market that use the VNC protocol, RealVNC is the one I
recommend.

The main advantage of the VNC protocol, as far as I’m concerned, is that it transmits a pixel-based view
of remote sessions. That means, considering the wide variety of screen resolutions between devices,
especially mobile, your view of a remote session will be as close to what would be displayed on the local
screen as possible. The downside is that pixel-based session views require greater data transmission
than application-based session views. Make sure that you have good, stable bandwidth from your internal
network if you choose to deploy a VNC remoting application like RealVNC.

RealVNC has all of the functionality of TeamViewer, except that there’s only a chat option for online
meetings, no VoIP or video conferencing.

Of the licenses that RealVNC sells, I would choose Enterprise. Only their Enterprise license offers 256-bit
AES encryption, their other licenses only offer 128-bit AES. As I mentioned before, I strongly believe that
remote sessions should be encrypted with a standard that uses at least 256-bit keys. Like TeamViewer,
RealVNC offers a free trial, and I recommend that you use that before making a commitment to the
application.

RealVNC supports all of the operating systems TeamViewer does, minus Windows Phone 8, but plus a
few Unix distros, including Solaris and AIX. RealVNC Server must be installed on each computer you’d be
remoting from, which can run Windows, OS X, GNU/Linux distros or Unix distros. Then, VNC Viewer can
be installed in any of those OSes plus Android or iOS, to remote to when away from the office.
Like with TeamViewer, I insist on running RealVNC over a VPN or a heavily secured WAN.

RealVNC can be downloaded from their website, http://www.realvnc.com.

LogMeIn

LogMeIn products use their own propriatery protocol. Windows or OS X based PCs can be remoted to.
LogMeIn Hamachi is being beta tested for GNU/Linux, but I wouldn’t install it on a GNU/Linux based PC
until the stable release becomes available. There’s no support for Unix distros as of yet. Whichever
LogMeIn application you use, you can remote to your local machine using Windows, OS X, Android or
iOS.

The LogMeIn applications that are appropriate for corporate use are Pro and Hamachi. LogMeIn Pro has
the features the business versions of TeamViewer and RealVNC have. LogMeIn Hamachi is special,
because it can virtualize your entire local network. So, if your Hamachi installation is configured to do so,
a remoting employee can access multiple clients and servers in your LAN, not just one particular
machine.

Both Pro and Hamachi secure communications with OpenSSL. In response to the Heartbleed bug, the
version of OpenSSL used has been tested and updated so that’s there’s no Heartbleed and no major
known vulnerabilities. LogMeIn offers different SSL ciphers. As I’ve mentioned, I would insist on using
256-bit AES, because the other SSL encryption standards have shorter bit length keys. In my professional
experience, if a cracker has a botnet and rainbow tables, anything less isn’t secure enough. If a
symmetric key is used, such as AES, you’re not making life difficult enough for a botnet wielding cracker
unless there’s at least a 256-bit key. I dream about when future versions of SSL/TLS use much more
complex keys, as that should make Internet communications more secure.

LogMeIn Pro is very similar to the other corporate remoting solutions I’ve mentioned. Install the server on
each licensed PC in your local network, and PCs and mobile devices with LogMeIn clients can access
individual machines. But as Hamachi virtualizes your entire LAN, you will need to install Hamachi server
software on a server machine in your LAN that has control of the clients you’d like to access.

Like all the other products I’ve mentioned, there are free trials available for Pro and Hamachi as well.
Definitely run a free trial before you decide to buy the software.

The Importance of a Good VPN

The remoting solutions I’ve mentioned offer VPNs. If your corporate network doesn’t have a WAN that’s
managed by security certified professionals, using VPNs is crucial. All of the products I’ve mentioned
encrypt their communciations, but I don’t believe that alone is enough. Banking institutions, militaries and
intelligence agencies run their already encrypted communications through VPNs. Given how affordable
and accessible that technology is these days, make sure your company does the same.
VPNs offer an additional layer of encryption and authentication, and the latest VPN technology shouldn’t
noticeably slow down your uploads and downloads at all. Certainly not the way a proxy network can.

PP2P, IPSec and SSL are all protocols that can be used. For best security and ease of use and
configuration, I recommend SSL whenever possible.

VPN Vulnerabilities

Like any other computing technology, there are VPN vulnerabilites that should be considered when
implemented.

When blackhats scan Internet activity for attractive targets, they may take particular interest in your VPN.
Unencrypted and partially encrypted communications might not be considered to be an attractive target. If
it’s not secret, it might not be a useful find. It can’t be too important if the parties didn’t bother encrypting
thoroughly, right? But VPN communications usually lead to lucrative, sensitive data in internal networks,
often including banking and credit card information.

The devices used to implement VPNs can usually be fingerprinted a bit, even by just openly revealing the
makes and models of the devices used. When a particular make and model is known to an attacker, they
can then research vulnerabilities that are specific to that device.

Just like with any other system that requires username and password authentication, if insecure
credentials are used, that’ll be the weakest point. All of the other security measures used become close to
useless if an adminstrator is “Admin,” with “password” or even “p455w0rd” as the password.
Change all defaults. Keep in mind that letter/number substitution isn’t such a clever method any more. All
of the dictionaries I’ve downloaded for dictionary crackers in the past few years c0nt4in the5e k1nd 0f
w0rd5. Also, you want passwords that contain no real words in any human language, and a combination
of upper and lower case letters, numbers, and special characters. Exhaust as much of the maximum
password length as possible. And if every username is your network is different and unique, that’s all the
better. For good measure, implement a policy that requires changing passwords every six months or so.

VPN communications are subject to Man-in-the-Middle attacks like any other network communications.
Make sure that your remoting solution has a specific MitM system. A well designed MitM system doesn’t
make such attacks impossible, but it’ll sure make them a lot more difficult, and may make a cracker give
up in frustration.

Make sure your remoting application lockouts accounts if a certain number of failed authentication
attempts are made. Otherwise, it’s easier for enough computing power with enough time to crack your
VPN communications.

When you configure a remoting system that uses the best security practices, your company can enjoy
convenience and flexibility without too much risk. Remoting security will continue to evolve, so keep up
with the latest products and technologies, or else your implemetation will lose security by obsolescence.
References

TeamViewer http://www.teamviewer.com

RealVNC http://www.realvnc.com

LogMeIn http://www.logmein.com

LogMeIn Hamachi Security Whitepaper http://help.logmein.com/KnowledgeLinkPublicRenderer?

type=Link&id=kA230000000NAoTCAW&search=0

How (and why) to set up a VPN today- PCWorld http://www.pcworld.com/article/2030763/how-and-why-

to-set-up-a-vpn-today.html

NTA VPN Security Flaws Whitepaper, Roy Hills

VPN Security Whitepaper, The Government of the Hong Kong Special Administrative Region