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

3. 4

4. HTTPS = HTTP + SSL/TLS
5

5. HTTPS = HTTP + SSL/TLS
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. TLS Protocol layers
• E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256
10

8. TLS Protocol layers
• E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256
11

9. TLS Protocol layers
• E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256
12

10. TLS Protocol layers
• E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256
13

11. TLS Protocol layers
• E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256
14

12. TLS Protocol layers
• E.g.: TLS_RSA_WITH_AES_128_CBC_SHA256
15

13. Vulnerability-Tolerant TLS
18

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. vtTLS in action
20

16. vtTLS in action
21

17. vtTLS in action
22

18. 23
Example of a
possible TLS
Handshake

19. 24
Example of a
possible vtTLS
Handshake

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)

27. vtTLS before protection
32

28. 33
Example of vtTLS
Application Data
Encryption
Process
Header

29. 34
Example of vtTLS
Application Data
Encryption
Process
Header
First IV
Message

30. 35
Example of vtTLS
Application Data
Encryption
Process
Header
First IV
Message
First MAC

31. 36
Example of vtTLS
Application Data
Encryption
Process
Header
First IV
Message
First MAC
= First Ciphertext

32. vtTLS with 1 layer of protection
37

33. 38
Example of vtTLS
Application Data
Encryption
Process
Second IV
First ciphertext

34. 39
Example of vtTLS
Application Data
Encryption
Process
Second IV
First ciphertext
Second MAC

35. 40
Example of vtTLS
Application Data
Encryption
Process
Second
ciphertext

36. vtTLS with 2 layers of protection
41

37. Experimental Evaluation
42

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. vtTLS
• Protocol TLS 1.2
• Code fork of
OpenSSL 1.0.2.g
44
https://github.com/inesc-id/vtTLS/wiki

40. Implementation
• OpenSSL is a very
complex library
• Approx. 440K lines of
code
• Well structured
• Optimized for
performance, not for
change
45

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