Recent vulnerability released by Google called Poodle - puts security administrators to scramble keeping up with "heartbleed", "retiring of SHA-1" and "removal of SSLv3" As I come from the solutions and enterprise architecture background, I get pinged by these questions about the real risk and impact of implementing these security enforcement's.
In my earlier blog post I've pointed out how pure inconvenience is not security, although I agree that security is not convenient. My answer to most of my customers begins with the question "Do you know the current dependency on these legacy protocols on your customers?" Whether it is internal or external customers, I have mostly had silence in response to this question. My attempt is not to use a "Socratic method" and make the requester scramble to more work before performing a security enhancement but to help the organization manage these type of security controls without crippling their customers.
So how do we even asses if these protocols are being used in the enterprise. Are there simple tools one can use to monitor the network for what SSL protocols are being used? If all your services are pretty much HTTPS and you have pretty homogeneous environment (IIS or Apache), this is bit easy using the log files to see what protocols customers are currently using. However it is hard to know if your customer base can use better protocols but fall back to less ideal protocols. Here is where packet analysis is powerful and can really help monitor the usage of SSL protocols and pursue a plan of action on how to enable appropriate protocols.
Tshark to the rescue. Wireshark has been a very popular open-source packet analyzer. Tshark is a terminal or command line version of wireshark useful in extracting interesting data from captured packets. This is useful for specific analysis like what we will attempt to do. We could load the output from tshark in text format or XML format to a database and do analysis. Below is the simple process:
Assuming you have a good sensor(s) that covers passively communications between your servers and customers (Read earlier blog on rolling PCAP). You can capture traffic over a 24 hour period using a Berkeley Packet Filter (BPF) express ( as simple "port 443 or port 8443") and capture all incoming traffic. You could break up the packet capture files into smaller chunks so the analysis can be run on multiple machine or a distributed system.
If you have these packet capture files in a repository. Now it is time to break this data to find what SSL handshake ciphers are actually being requested by your customer base. Lets assume you have a number of packets and are ready to analyze these using tshark
This basically tells us the client system that tried to talk to our server provided 10 SSL ciphers that it can support and some of these are weak SSL2 and some of these TLS1 with still limited encryption capability. Our server seems to have chosen the best possible cipher given the client's limitation. This tells me that there will be some customer impact if I disable all TLS ciphers with 3DES and CBC (at least one customer right?).
You can now further take this analysis to load data into a database - event a datamart - through a simple ETL load for once to do further analysis. You could abstract and collect the cipher information as pure hexadecimal 3 Byte or a 24-bit number to analyze which protocols to minimum support on your network.
The above command will only collect the successfully negotiated SSL cipher between client and server. This can be very helpful way to quickly look at what SSL ciphers to minimum support in your environment. Once you have analyzed this you can push a policy either in your web application firewalls or on the servers to ensure your clients will always have a secure and still usable browsing experience to your online services.
Now you can rest till the next SSL exploit - probably in three to four weeks.
In my earlier blog post I've pointed out how pure inconvenience is not security, although I agree that security is not convenient. My answer to most of my customers begins with the question "Do you know the current dependency on these legacy protocols on your customers?" Whether it is internal or external customers, I have mostly had silence in response to this question. My attempt is not to use a "Socratic method" and make the requester scramble to more work before performing a security enhancement but to help the organization manage these type of security controls without crippling their customers.
So how do we even asses if these protocols are being used in the enterprise. Are there simple tools one can use to monitor the network for what SSL protocols are being used? If all your services are pretty much HTTPS and you have pretty homogeneous environment (IIS or Apache), this is bit easy using the log files to see what protocols customers are currently using. However it is hard to know if your customer base can use better protocols but fall back to less ideal protocols. Here is where packet analysis is powerful and can really help monitor the usage of SSL protocols and pursue a plan of action on how to enable appropriate protocols.
Tshark to the rescue. Wireshark has been a very popular open-source packet analyzer. Tshark is a terminal or command line version of wireshark useful in extracting interesting data from captured packets. This is useful for specific analysis like what we will attempt to do. We could load the output from tshark in text format or XML format to a database and do analysis. Below is the simple process:
If you have these packet capture files in a repository. Now it is time to break this data to find what SSL handshake ciphers are actually being requested by your customer base. Lets assume you have a number of packets and are ready to analyze these using tshark
| [user@unix4]$ tshark -V -nr /tmp/problems.dmp --- Secure Sockets Layer SSLv2 Record Layer: Client Hello [Version: SSL 2.0 (0x0002)] Length: 55 Handshake Message Type: Client Hello (1) Version: TLS 1.0 (0x0301) Cipher Spec Length: 30 Session ID Length: 0 Challenge Length: 16 Cipher Specs (10 specs) Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005) Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004) Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009) Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008) Challenge
---truncated---
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jan 15, 2025 02:47:33.000000000 GMT
random_bytes: 059451b62a98496ec9e50ed98511347f0d7b6c6d593a7d75..
.
Session ID Length: 32
Session ID: 7fac75136b8748eda80e831b350beee76d575b1b36fdcbec...
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Compression Method: null (0)
----truncated----
|
This basically tells us the client system that tried to talk to our server provided 10 SSL ciphers that it can support and some of these are weak SSL2 and some of these TLS1 with still limited encryption capability. Our server seems to have chosen the best possible cipher given the client's limitation. This tells me that there will be some customer impact if I disable all TLS ciphers with 3DES and CBC (at least one customer right?).
You can now further take this analysis to load data into a database - event a datamart - through a simple ETL load for once to do further analysis. You could abstract and collect the cipher information as pure hexadecimal 3 Byte or a 24-bit number to analyze which protocols to minimum support on your network.
| [user@unix4]$ tshark -n -T fields -e ssl.record.version -r problems.dmp 0x0002 0x0301 0x0301,0x0301 0x0301 0x0301,0x0301 0x0301,0x0301 0x0301,0x0301 0x0301 0x0301,0x0301 0x0301,0x0301 |
The above command will only collect the successfully negotiated SSL cipher between client and server. This can be very helpful way to quickly look at what SSL ciphers to minimum support in your environment. Once you have analyzed this you can push a policy either in your web application firewalls or on the servers to ensure your clients will always have a secure and still usable browsing experience to your online services.
Now you can rest till the next SSL exploit - probably in three to four weeks.
No comments:
Post a Comment