Securing the channel - Tarkay Jamaan


Published on

Presented in OWASP Qatar Chapter Meeting - June 2013

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Securing the channel - Tarkay Jamaan

  1. 1. 1 Securing the Channel Tarkay Jamaan ictQatar
  2. 2. 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. 3. 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. 4. 4 The Problem Alex Consider this scenario: Alex followed a phishing link to a site that imitates his e-bank.
  5. 5. 5 The Problem Alex Now the fake site can steal Alex's account and money!
  6. 6. 6 The Problem Alex Charles Consider this scenario: Alex wants to access his bank account and do some transactions.
  7. 7. 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.
  8. 8. 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! $$$
  9. 9. 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. 10. 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. 11. 11 Identity A certificate can verify a site's identity ● Alex can now verify the e-bank's identity with the certificate. – How?
  12. 12. 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. 13. 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. 14. 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. 15. 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. 16. 16 Confidentiality and Integrity ● It is important to choose strong algorithms for the cipher suite.
  17. 17. 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.
  18. 18. 18 Common Mistakes ● Never use self-signed certificates in production
  19. 19. 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. 20. 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. 21. 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. 22. 22 OWASP best practices (cont.) ● Do Not Mix TLS and Non-TLS Content ● Use "Secure" Cookie Flag
  23. 23. 23 OWASP best practices (cont.) ● Keep Sensitive Data Out of the URL ● Prevent Caching of Sensitive Data ● Use HTTP Strict Transport Security
  24. 24. 24 OWASP best practices (cont.) ● Server Certificate and Protocol Configuration: ● Use an Appropriate Certification Authority for the Application's User Base
  25. 25. 25 OWASP best practices (cont.) ● Only Support Strong Protocols – Don't use SSLv2! ● Only Support Strong Cryptographic Ciphers
  26. 26. 26 OWASP best practices (cont.) ● Only Support Secure Renegotiations ● Disable Compression ● Use Strong Keys & Protect Them
  27. 27. 27 OWASP best practices (cont.) ● Use a Certificate That Supports Required Domain Names ● Use Fully Qualified Names in Certificates ● Avoid Using Wildcard Certificates
  28. 28. 28 OWASP best practices (cont.) ● Do Not Use Private Addresses (RFC 1918) in Certificates ● Always Provide All Needed Certificates
  29. 29. 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. 30. 30 More Information For more information: er_Protection_Cheat_Sheet