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.
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. 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
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
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
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. 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. 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. 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. 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. 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. 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)
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
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. 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. 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. 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