Validating Security Protocols with Cloud-Based
Middleboxes
Curtis R. Taylor and Craig A. Shue
Worcester Polytechnic Institute
October 18, 2016
Communications and Network Security
(CNS)
1
Outline
• Introduction
– Secure connection establishment
• TLS
– Background and motivation
– Verification and revocation of certificates
• TLSDeputy
– Residential networks
– SDN + cloud for TLS verification and revocation
• Security evaluation
• Performance impact
2
Secure Connection Establishment
• Security related information exchange
happens early in a connection
• Examples:
– TLS (SSL), SSH, IPSec, …
3
Why TLS?
• Widespread usage
• Easy to get wrong
– IoT devices in particular
– Browsers do a reasonable job of verification
• Revocation ecosystem [Liu15]
– Heartbleed
[Liu15] Liu, Yabing, et al. "An end-to-end measurement of certificate revocation in the web's PKI."
Proceedings of the 2015 ACM Conference on Internet Measurement Conference. ACM, 2015.
4
TLS Connection
Implemented differently,
if at all, by each device.
5
TLS Verification
• Purpose:
– Ensure the certificate received was issued (signed) by
a trusted certificate authority (CA)
• Valid dates, common name matches, etc.
– Prevents a man-in-the-middle (MITM) attack using
self-signed certificates
Root
Store this locally!
Root
Intermediate2
Intermediate1
Leaf
Detect this was
not signed by a
trusted CA!
Intermediate3
Leaf
Leaf
6
TLS Revocation
• Purpose:
– Ensure verified certificate has not been revoked
– Prevents a leaked private key from continuing to be
used
• Three methods to check revocation:
1. CRL (certificate revocation list)
•
URL to CRL embedded in certificate
2. OCSP (online certificate status protocol)
• CA support necessary
3. OCSP-stapling
•
End-server support necessary
7
TLSDeputy
Device traffic
OpenFlow PacketIn
OpenFlow FlowMod
This is a TLS connection.
Install
flows for
router flows
and
Certs verify!
Remove
z
TLSDeputy
causing MB redirection.
I need to phone
home using TLS
Certificate (1)
Certificate (2)
Results of verify(…) and rev_status(…) are
used by TLSDeputy to direct the OFA to
create an OpenFlow packet that tlsdeputy
will use to allow/deny the TLS flow.
verify(cert1,cert2, store)
rev_status(cert1,cert2, store)
8
Security Evaluation (1)
1. Verification check
– Attempt MITM attack
•
Send self-signed root cert
2. Revocation check
– Revoked leaf certificate in CRL on server
and update CRL
•
Keep providing revoked certificate
9
Security Evaluation (2)
10
Performance
1. Overhead of checking leaf certificate only
2. Overhead of performing full chain
revocation checks
– The smart thing to do!
11
Cumulative Distribution (40k Trials)
Revocation: Leaf Certificate Only
1
0.8
0.6
0.4s
0.4
TLS verify only
CRL
OCSP
TLSDeputy
0.2
0
0
0.5
1
Latency (s)
Overhead
(s)
1.5
2
12
Cumulative Distribution (10k Trials)
Revocation: Full Chain
1
0.8
0.6
0.4
0.2
Trad. CRL
TLSDeputy
0
0
0.5
1
1.5
2
2.5
Overhead (s)
3
3.5
4
13
Summary and Future Work
• TLS verification and revocation are often
performed incorrectly or not at all
• TLSDeputy is a cloud-based middlebox that
performs validation of certificates
independently
– Introduces minimal delay in establishing TLS
connections
– OFA allows direct connection after MB validation
• Larger scale deployment with IRB approved
study
14
Questions?
15
Session Talks
• Automated Synthesis of Resiliency Configurations for
Cyber Networks
– Mohammad Ashiqur Rahman (Tennessee Tech University, USA); Abdullah Al Farooq
(University of North Carolina at Charlotte, USA); Amarjit Datta (Tennessee Tech
University, USA); Ehab Al-Shaer (University of North Carolina Charlotte, USA)
• Text Mining for Security Threat Detection Discovering
Hidden Information in Unstructured Log Messages
– Candace Suh-Lee, Ju-Yeon Jo and Yoohwan Kim (University of Nevada, Las Vegas, USA)
• Validating Security Protocols with Cloud-Based
Middleboxes
– Curtis Taylor and Craig A. Shue (Worcester Polytechnic Institute, USA)
16
Additional Slides
17
TLSDeputy
Questions to answer:
1.
How does the OFA construct OF messages that only the
corresponding controller application will receive the notification?
• Can we limit only ssld to seeing related traffic?
– Yes, via DPID? First 48 bits are MAC, last 16 bits “vendor specified” could differentiate
up to 65k apps
• Can arbitrary information be relayed in the packet? For example, the headers
(TCP/IP) may be the actual SSL flow in question but a fake payload could contain
information related to the connection (remove flow to MB or drop connection at
residential router due to […], which is an SSLDeputy specific reason such as
invalid cert or revocation)
2.
How to relay to client that verification and/or revocation was
unsuccessful?
•
•
•
•
TCP RST or drop final handshake cert
Does client have any alternative?
Allow connection and see if client fails validation?
What if client has self-signed cert?
–
3.
Exceptions on per device basis?
At what rate to we need to update CRLs?
•
4.
•
Should be based on the number of intermediate and root CAs? Which is?
Can we modify SSL’s ClientHello to include OCSP support and MITM
the handshake to improve performance. Are there cases that OCSP
removes CRL information?
18
No. Naturally, this is protected via an integrity check
A MITM for OSCP:
Introducing Security and Performance
• Idea: use SSLDeputy to inject OCSP request (capability) into
the ClientHello as part of the SSL handshake
– Packet modifications required to ClientHello
• Update ClientHello total length
• Update Extensions Length +=9 bytes then append the following bytes
–
–
–
–
–
Type: status_request 0x0005 (2 bytes)
Length: 0x0005 (2 bytes denoting x = [9-2]-2 bytes)
Status type: 0x01 (1 byte meaning OCSP)
Responder ID list: 0x0000 (2 bytes)
Request extensions list: 0x0000 (2 bytes)
• Does the order of extensions matter? That is, can we just tack it on to
the end? Some example requests show it being next to last
– If OCSP is enabled at the destination server
• Unsure of complete changes here, if any are possible
1.
2.
3.
Will clients ignore OSCP response if not supported?
Can OSCP be recursive? Don’t think so but could Server ask an Intermediate
CA to append a stapled response from another CA in the chain?
So far, it appears that if using OCSP, the CRL extension is not disregarded in
response. This means as long as client ignores OCSP, the approach should be
backwards compatible.
– If confirmed by SSLDeputy not to be supported, no changes to
the server response are necessary
19
Motivation for IoT and Residential
Networks
1.
IoT devices have poor SSL implementations
–
2.
3.
4.
5.
6.
Examples: Smart TV, WiFi Kettle, others?…
Recent work has shown the revocation system to be a thoroughly
lacking
SSLNotary could help (partially) but still need intervention
(SDN/MB)
IoT is going to be deployed on home networks with limited
resources(Cloud)
SSLDeputy is an example of a MB that needs only initial
connection information (certificates or re-establishment) and would
like to communicate to controller to stop sending traffic through the
MB or to drop the traffic (Participatory networking)
We want a solution that will work (i.e., backwards compatibility and
partial deployment) with an existing SDN (OpenFlow) controllers
and standards. (Unlike Brown’s work)
–
Could we still offer same theoretical benefits?
20
Dataset Specifics on
Revocation
• Leaf certs
– 99.9% of certs have a “potentially reachable” CRL distribution
point
• Ignored, for example, ldap:// and file:// URLs
– 95% of certs have a “potentially reachable” OSCP responder
– 0.09% (4,394) have neither
• That is, can never be revoked
• Intermediate certs
– 98.9% of certs have a “potentially reachable” CRL distribution
point
– 48.5% of certs have a “potentially reachable” OSCP responder
– 0.92% (18) have neither
• 2,800 unique CRL distribution points for all certs
– Downloaded once per day over study
• 499 unique OCSP responders for all certs
– Expensive – only used for 642 certs total (those that only had
OCSP)
21
3) Client Behavior
22