1

Securing the Channel

Tarkay JamaanictQatar

2

Introduction

● Traffic from client to server travels through computers that are outside their control. These computers can see the network packets going through and modify them.

3

Introduction

● This becomes an issue when the communication channel between a client and server is unencrypted, as malicious entities might sniff or alter communications (e.g. man-in-the-middle attacks).

● Thus, we need a way to ensure the confidentiality and integrity of the communication channel.

4

The Problem

Alex

superloank.com

superbank.com

Consider this scenario:Alex followed a phishing link to a site that imitates his e-bank.

5

The Problem

Alex

superloank.com

superbank.com

Now the fake site can steal Alex's account and money!

6

The Problem

Alex

Charles

Consider this scenario:Alex wants to access his bank account and do some transactions.

superbank.com

7

The Problem

Alex

Charles

Charles executed a man-in-the-middle attack (e.g. arp poisoning) to become between Alex and the E-banking site.

superbank.com

8

The Problem

Alex

Charles

Charles can now see and manipulate all traffic between Alex and the E-Banking site!Charles can also claim to be the bank itself!

superbank.com

$$$

9

Solving the Problem

● We need a way to:– Verify the identities of the end points.

– Ensure the confidentiality of the data transferring between Alex and the e-bank.

– Ensure the integrity of the data transferring between Alex and the e-bank.

10

Solving the Problem

● Certificates to the rescue!– Certificates can verify the identity of the server.

● The server still needs to verify the client identity using credentials.

– Certificates help encrypt communication between a client and a server.

● Using Secure Socket Layer (SSL) or Transport Layer Security (TLS).

– If you ever used “https” you used a certificate!

11

Identity

A certificate can verify a site's identity

● Alex can now verify the e-bank's identity with the certificate.

– How?

12

Identity

● Alex is using a certificate hierarchy chain to verify that the certificate received is legit.

● Each certificate is verified by its parent.● There need to be some trusted root

certificates.– Your browsers come with some preinstalled.

– Your organization can add more.

13

Identity

● The e-bank can verify Alex using an authentication system with credentials.

– But we need to send the credentials encrypted to avoid sniffing!

– Use TLS for this.

An example of an authentication system

14

Confidentiality and Integrity

● TLS can ensure that data transmitted in a secure connection is confidential using encryption.

– A side effect of this is that the data integrity is also ensured.

15

Confidentiality and Integrity

● TLS works using two things:– Cipher suite

● A collection of algorithms related to encryption such as key exchange algorithms, bulk encryption algortithms, message authentication algorithms, and pseudorandom function algorithm.

– Server certificate

16

Confidentiality and Integrity

● It is important to choose strong algorithms for the cipher suite.

17

Where to get a certificate?

● For internal applications: If your organization has a certificate authority you get it from there.

● For external applications: Use an internet certificate authority.

– e.g. www.thawte.com

18

Common Mistakes

● Never use self-signed certificates in production

19

Common Mistakes

● Never use self-signed certificates in production– There is no way to tell the difference between

a legit self-signed certificate and a self-signed certificate made by an attacker.

– You are training users to ignore security warnings.

20

Common Mistakes

● Using TLS secures the channel, but doesn't make your servers safe from attackers.

– The only difference is that now the attacker needs to use TLS secured traffic.

21

OWASP best practices

● Secure Server Design:● Use TLS for All Login Pages and All

Authenticated Pages● Use TLS on Any Networks (External and

Internal) Transmitting Sensitive Data ● Do Not Provide Non-TLS Pages for Secure

Content

22

OWASP best practices (cont.)

● Do Not Mix TLS and Non-TLS Content● Use "Secure" Cookie Flag

23

OWASP best practices (cont.)

● Keep Sensitive Data Out of the URL● Prevent Caching of Sensitive Data● Use HTTP Strict Transport Security

24

OWASP best practices (cont.)

● Server Certificate and Protocol Configuration:● Use an Appropriate Certification Authority for

the Application's User Base

25

OWASP best practices (cont.)

● Only Support Strong Protocols– Don't use SSLv2!

● Only Support Strong Cryptographic Ciphers

26

OWASP best practices (cont.)

● Only Support Secure Renegotiations● Disable Compression● Use Strong Keys & Protect Them

27

OWASP best practices (cont.)

● Use a Certificate That Supports Required Domain Names

● Use Fully Qualified Names in Certificates ● Avoid Using Wildcard Certificates

28

OWASP best practices (cont.)

● Do Not Use Private Addresses (RFC 1918) in Certificates

● Always Provide All Needed Certificates

29

Summary

It is essential to secure the channel before attempting to handle any sensitive data to avoid data leakage, man-in-the-middle attacks, and the consequences of insecure communication.

OWASP provides some guidelines that will help you implement transport layer protection (SSL/TLS).

30

More Information

For more information:

https://www.owasp.org

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet