Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Vulnerability-tolerant Transport Layer Security

102 views

Published on

More information at: https://github.com/inesc-id/vtTLS/wiki

Vulnerability-tolerant Transport Layer Security (vtTLS) - Work presented at OPODIS 2017 on December 20th 2017

SSL/TLS communication channels play a very important role in Internet security, including cloud computing and server infrastructures. There are often concerns about the strength of the encryption mechanisms used in TLS channels. Vulnerabilities can lead to some of the cipher suites once thought to be secure to become insecure and no longer recommended for use or in urgent need of a software update. However, the deprecation/update process is very slow and weeks or months can go by before most web servers and clients are protected, and some servers and clients may never be updated. In the meantime, the communications are at risk of being intercepted and tampered by attackers.

In this presentation (and in the paper) we propose an alternative to TLS to mitigate the problem of secure communication channels being susceptible to attacks due to unexpected vulnerabilities in its mechanisms. Our solution, called Vulnerability-Tolerant Transport Layer Security (vtTLS), is based on diversity and redundancy of cryptographic mechanisms and certificates to ensure a secure communication even when one or more mechanisms are vulnerable. Our solution relies on a combination of k cipher suites which ensure that even if k − 1 cipher suites are insecure or vulnerable, the remaining cipher suite keeps the communication channel secure. The performance and cost of vtTLS were evaluated and compared with OpenSSL, one of the most widely used implementations of TLS.

Published in: Science
  • Be the first to comment

  • Be the first to like this

Vulnerability-tolerant Transport Layer Security

  1. 1. André Joaquim, Miguel L. Pardal, Miguel Correia INESC-ID, Instituto Superior Técnico, Universidade de Lisboa Lisboa, Portugal Vulnerability-Tolerant Transport Layer Security December 20th, 2017
  2. 2. project [EU H2020] • Secure Storage • Secure Queries • Secure Communications – Same properties as secure channels (TLS) • Authentication of endpoints • Confidentiality • Integrity – Assuming very powerful adversaries that may break some of the usual assumptions 3
  3. 3. 4
  4. 4. HTTPS = HTTP + SSL/TLS 5
  5. 5. HTTPS = HTTP + SSL/TLS 6
  6. 6. What are the problems? • Many vulnerabilities have been discovered in TLS – in the protocol specification and in the implementations • TLS uses only one cipher suite • TLS supports deprecated mechanisms 8
  7. 7. TLS Protocol layers • E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256 10
  8. 8. TLS Protocol layers • E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256 11
  9. 9. TLS Protocol layers • E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256 12
  10. 10. TLS Protocol layers • E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256 13
  11. 11. TLS Protocol layers • E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256 14
  12. 12. TLS Protocol layers • E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256 15
  13. 13. Vulnerability-Tolerant TLS 18
  14. 14. 19 vtTLS architecture • Protocol for diverse and redundant vulnerability-tolerant communication channels • Client and server negotiate k cipher suites • A subset of the k cipher suites are used to secure the messages during communication
  15. 15. vtTLS in action 20
  16. 16. vtTLS in action 21
  17. 17. vtTLS in action 22
  18. 18. 23 Example of a possible TLS Handshake
  19. 19. 24 Example of a possible vtTLS Handshake
  20. 20. Combining cipher suites 25 • Combining diverse cipher suites is not trivial • Different metrics for prioritization of mechanisms: – Perfect forward secrecy – Disjoint mathematical hard problems
  21. 21. Combining hash functions • SHA-1 + SHA-3 – Not possible in vtTLS as SHA-1 is not recommended and TLS 1.2 does not support SHA-3 • SHA-1 + Whirlpool – Not possible in vtTLS as SHA-1 is not recommended and TLS 1.2 does not support Whirlpool • SHA-2 + SHA-3 – Also not possible in vtTLS as TLS 1.2 does not support SHA-3 • Some diversity still possible by using different variants of SHA-2: SHA-256 and SHA-384 26
  22. 22. Combining public key encryption • Used for authentication and key exchange • DSA + RSA – Possible as TLS 1.2 supports both functions for authentication – However, TLS 1.2 specific cipher suites only support DSA with elliptic curves (ECDSA) • DSA + Rabin-Williams – Not possible as TLS 1.2 does not support Rabin-Williams • RSA + ECDH – Possible as TLS 1.2 supports both functions for key exchange • RSA + ECDSA – Possible as TLS 1.2 supports both functions for authentication 27
  23. 23. Combining public crypto for authentication • Most diverse combination: DSA + RSA • TLS 1.2 preferred cipher suites use ECDSA instead of DSA – Using elliptic curves results in faster computation and lower power consumption • Preferred combination for authentication: RSA + ECDSA 28
  24. 24. Combining public crypto for key exchange • Most diverse combination: RSA + ECDH – To grant perfect forward secrecy, the ECDH with Ephemeral keys (ECDHE) has to be employed • Preferred combination for key exchange: RSA + ECDHE 29
  25. 25. Combining symmetric ciphers • AES supported by TLS 1.2 • Camellia also supported by TLS 1.2 • The most diverse combination is AES256-GCM + CAMELLIA128-CBC – But there is no cipher suite that uses RSA for key exchange, Camellia for encryption, SHA- 2 for MAC in OpenSSL 1.0.2.g • AES256-GCM + AES128 – Possible as TLS 1.2 supports both functions 30
  26. 26. Current choice of cipher suites (k=2) 31 • The combination we chose is – ECDHE-ECDSA + AES-256-GCM + SHA384 (SHA-2) – RSA + AES-128-CBC + SHA256 (SHA-2)
  27. 27. vtTLS before protection 32
  28. 28. 33 Example of vtTLS Application Data Encryption Process Header
  29. 29. 34 Example of vtTLS Application Data Encryption Process Header First IV Message
  30. 30. 35 Example of vtTLS Application Data Encryption Process Header First IV Message First MAC
  31. 31. 36 Example of vtTLS Application Data Encryption Process Header First IV Message First MAC = First Ciphertext
  32. 32. vtTLS with 1 layer of protection 37
  33. 33. 38 Example of vtTLS Application Data Encryption Process Second IV First ciphertext
  34. 34. 39 Example of vtTLS Application Data Encryption Process Second IV First ciphertext Second MAC
  35. 35. 40 Example of vtTLS Application Data Encryption Process Second ciphertext
  36. 36. vtTLS with 2 layers of protection 41
  37. 37. Experimental Evaluation 42
  38. 38. Implementation 43 • Option 1: Implement vtTLS from scratch – Would take a long time – Could have possible implementation vulnerabilities • Option 2: Modify an existent TLS (OpenSSL) implementation to support vtTLS – Widely used and tested – Less entry barriers
  39. 39. vtTLS • Protocol TLS 1.2 • Code fork of OpenSSL 1.0.2.g 44 https://github.com/inesc-id/vtTLS/wiki
  40. 40. Implementation • OpenSSL is a very complex library • Approx. 440K lines of code • Well structured • Optimized for performance, not for change 45
  41. 41. 46 Average of the handshake length (ms) 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 vtTLS OpenSSL Establishing a connection is 66.7% slower
  42. 42. 47 Average time to send/receive a message (ms) 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 1 MB 10 MB 50 MB 100 MB 500 MB 1 GB Message Size vtTLS Send vtTLS Receive OpenSSL Send OpenSSL Receive Takes just 22.9% longer to send messages
  43. 43. 48 0 1 2 3 4 5 6 100 000 1 000 000 100 000 000 vtTLS OpenSSL % of increased size of the encrypted message Negligible message size increase
  44. 44. Evaluation summary • vtTLS is, in average, 66.7% slower establishing a connection • A message sent through a vtTLS channel takes in average 22.9% longer • Sending 100 MB through a vtTLS channel costs an additional approx. 405 KB 49
  45. 45. Conclusion • vtTLS is a protocol for diverse and redundant vulnerability-tolerant secure communication channels • Provides an interesting trade-off for a set of critical security applications • Viable for non-timely critical applications 50
  46. 46. Future Work • Optimize handshake, reuse sessions • Use more mechanisms when available – SHA-3 and Camellia • Introduce diversity of implementations • Compare vtTLS with TLS-over-TLS tunneling 51
  47. 47. 52 Thank you! Miguel.Pardal@tecnico.ulisboa.pt http://www.safecloud-project.eu/ This work was supported by the European Commission through project H2020-653884 (SafeCloud) and by national funds through Fundação para a Ciência e a Tecnologia (FCT) with reference UID/CEC/50021/2013 (INESC-ID) Slide contributions: André Joaquim, Ricardo Moura, Sree Harsha Totakura

×