• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Securing the channel - Tarkay Jamaan

Securing the channel - Tarkay Jamaan



Presented in OWASP Qatar Chapter Meeting - June 2013

Presented in OWASP Qatar Chapter Meeting - June 2013



Total Views
Views on SlideShare
Embed Views



1 Embed 2

https://twitter.com 2



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Securing the channel - Tarkay Jamaan Securing the channel - Tarkay Jamaan Presentation Transcript

    • 1 Securing the Channel Tarkay Jamaan ictQatar
    • 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_Lay er_Protection_Cheat_Sheet