Most IT people are somewhat familiar with Wireshark.  It is a traffic analyzer, that helps you learn how networking works, diagnose problems and much more.

2015-02-11 22_29_11-

One of the problems with the way Wireshark works is that it can’t easily analyze encrypted traffic, like TLS.  It used to be if you had the private key(s) you could feed them into Wireshark and it would decrypt the traffic on the fly, but it only worked when using RSA for the key exchange mechanism.  As people have started to embrace forward secrecy this broke, as having the private key is no longer enough derive the actual session key used to decrypt the data.  The other problem with this is that a private key should not or can not leave the client, server, or HSM it is in.  This lead me to coming up with very contrived ways of man-in-the-middling myself to decrypt the traffic(e.g. sslstrip or mitmproxy).

Session Key Logging to the Rescue!

Well my friends I’m here to tell you that there is an easier way!  It turns out that Firefox and Chrome both support logging the symmetric session key used to encrypt TLS traffic to a file.  You can then point Wireshark at said file and presto! decrypted TLS traffic.  Read on to learn how to set this up. Read Full Article

I was thinking about this question the other day.  It SEEMS obvious…  I relialized that it relates to one of my favourite misconceptions about https or SSL/TLS.  Often people get too focused on the encryption aspect of SSL/TLS and not the authenticity and verification properties of it.  When Google first announced that Google search was going to be over “https” a few years ago I, like a lot of people, assumed that it was because it was to make your search results private.


Google’s support page, regarding SSL Search, quite correctly points out:

SSL doesn’t always protect:

  • The fact that you visited
  • The search terms that you typed


Read Full Article

VPN Introduction

I have been doing some work with VPNs lately, having set up a PPTP(Point to Point Tunneling Protocol) VPN for some Android network analysis that I have been doing lately.  It is easy to set up on a server and a mobile device, but PPTP generally isn’t secure unless you are using (P)EAP.  I wanted to try out something that overlaps with something that I’m pretty knowledgeable about, TLS/SSL, with something I have never had to actually set up, an SSL VPN.  Most people who use a VPN to connect into work use an SSL VPN.  Probably either from someone like Cisco or Juniper.  They are pretty easy to set up on the router side of things, and relatively easy for client device to get set up.  Other advantages are that they can be run over port 443, so they won’t be blocked by most firewalls, and that they use the verification properties inherent to TLS/SSL rather than some sort of challenge-response handshake.  Using TLS/SSL allows them to also be flexible about key sizes and cipher suites used and upgrade them as the future requires.
Read Full Article

I’m very excited to announce the launch of AM I SHA-1 – the SHA-1 Checkinator. This is a site that I have been working on for a few months off and on. Ever since Google announced that they were going to sunset support for SHA-1 support in Chrome, I felt that it would be cool to have an easy site to check your SSL/TLS certs. It isn’t difficult to check your certificates yourself, but not everyone is able to analyze their own certificates and understand the context under which they need to act to upgrade their certificates before the end of 2016. The tool/site I made takes a URL and downloads and parses the certificates for a site, and then helps you determine what action if any is required on your certificates. I realize that there are several tools out there that check for this already, but most of these are bundled into more extensive tests and the tests often take a long time to run. My goal with this site, was to be lean and quick so I focused on just checking for the presence of SHA-1 signatures in chain and leaf certificates. Plus it was a great learning experience.
Read Full Article

The Setup

I have been testing out different ways to optimize this site for performance, purely as a learning experience.  I have come across several guides explaining how server-side caching works, some of them are really good, and some of them a bit out of date in terms of what I consider “best practice” in the industry these days.  Most of the guides to server side-caching do not include the notion of SSL/TLS.  Just like setting up a web server with SSL/TLS is more complex than setting up a web server without, setting up a cache with SSL/TLS is more complex than setting up a cache without.  The goal of this article is to discuss some of the most popular methods and some of their advantages/disadvantages.

This article will be more about the overarching concepts and flow of information than actual configuration, but I’m hoping to do articles on how to actually configure the different options in future posts and incorporate them into this article.
Read Full Article

PKI vs. CA

First we need to get a few terms straight.  I have heard the terms public key infrastructure(PKI) and certificate authority(CA) sometimes used in conversation interchangeably.  The difference is that a CA by itself doesn’t perform all of the functions of a PKI.  PKIs contain CAs, but they also have other components like certificate revocation lists(CRLs), online certificate status protocol(OCSP) responders that allow clients a higher degree of certainty when assessing whether or not a certificate is valid, even things like policy, which allows you to specify what kinds of certificates or what attributes can be signed by CAs within the PKI.

What is AD CS?

Active Directory Certificate Services(AD CS) is made by Microsoft and it is what a lot of companies use for their PKI needs.  It works well, gives you nice ways to interact with it and runs on Windows Server.  You can request certificates through a (somewhat ugly) web interface, you can also request/issue certificates through a Microsoft Management Console(MMC),  you can request/issue certificates at the command-line with certutil/certreq.  AD CS even handles things like CRL publishing over FTP or SMB and running an OCSP responder, in concert with IIS.  Even though certificate revocation is utterly broken in the consumer world, many PKI uses in the enterprise, e.g. EAP-TLS, generally require revocation to be ‘working’.
Read Full Article

With the recent interest in TLS, due to Heartbleed and the concerns about privacy due to the actions of certain agencies responsible for national security, there has been some really good discussion about TLS and how it is implemented.  Many people have talked about cipher suites in the context of server configuration.  Basically they have talked about how to set up your servers to only use secure protocols(no SSLv2, and no SSLv3 if you can get away with it), secure key exchange(preferring Perfect Forward Secrecy mechanisms), secure symmetric ciphers(AES-GCM, AES-CBC, and 3-DES if you have to) and good integrity checks a.k.a. HMACs(e.g. not using MD5, SHA-1).  While I love this discussion and am glad it seems to be getting moving in the right direction, I think it is also important to talk about what is going on with clients.  The configuration of my servers is important to the people who connect to my servers(all twelve of you), but it doesn’t affect the rest of my web browsing.  If I’m on my banks website browsing with IE8 on Windows XP, the security of my web server configuration doesn’t make me any more secure :).  In this article I am going to talk about which cipher suites the different browsers support, how they negotiate, and I will speculate a bit on the different design decisions made by each vendor.  I will also list whether Server Name Indication is supported or not.  This isn’t really a feature that improves security per sé, but it is important in terms of moving things forward as IPv4 addresses get more and more scarce.

Read Full Article