SSL and DLP: Little Known Secret
July 1, 2008 – 1:00 am by Lord Ravenclaw
Sniffing
I’m not sure about all of you, but I hate using public WiFi access points. Why? They’re quite insecure. You might ask yourself, “What does he mean by that?” Public WiFi access points are a hotspot (pun intended) for people looking to prey on others through packet sniffing. As you surf the internet, you’ll likely enter many passwords, either by web form, instant messenger application, email client, or any other number of applications. This data can be easily intercepted by other WiFi users by putting their WiFi cards into a mode known as promiscuous mode. In this mode the wireless card captures and logs all the packets it receives and is generally loaded into any number of programs for Windows, Mac, and Linux. Frequently this is used to break secured WiFi passwords by capturing parts of password packets sent to the base station. However, it’s more often used to capture data by other users on a WiFi network.
As a side note, this can be done by any network card wired or wireless, though generally wired networks use switches rather than hubs, which route data to the proper network port using a MAC address lookup table. If you’ve ever tried to get 100mbit out of your 10/100mbit hub between PCs, you notice that you can’t get the full speed from it as it frantically sends all of the data moving through every port to every other port (this is aside from the harddrive being unable to keep up) It’s a dumb repeater, whereas a switch will intelligently route the data and prevent data collisions.
Back to packet sniffing. I myself have done this in the past. Sitting at the airport for hours lends one to be quite bored. I’d frequently pull out my laptop and start capturing packets. Within minutes I’d have a couple email passwords, AIM passwords, and any number of other authentication tokens. Many times I’d find other security vulnerabilities, and even open shares.
What can you do to avoid this? Personally, what I do is use the DLP server as a proxy, and use iptables to block off all incoming traffic to my laptop. By using SSH (secured shell) in a certain mode, it acts as a SOCKS 5 proxy listening only on localhost. Those who know what SSH is know that SSH is generally used as a remote terminal, however in SOCKS 5 proxy mode it acts as a completely (or, as completely as one can be) secure proxy. This is my favorite method of securing my browsing from prying eyes around me. But frequently, one doesn’t have SSH access, or it’s not feasible. Maybe you just don’t want people prying in on what you’re browsing. However, this is somewhat slow, and I rarely feel like completely setting it up when all I plan to do is surf DLP.
I’m sure all of you who read this blog are going: “Get to the point, Raven.”
The Point
DLP, and PatronusCharm both have SSL URLs. It’s not a fact I’ve advertised greatly, but since I find it so useful, perhaps others will too. The following sites can be reached via SSL, which is an encrypted form of transporting data between a browser and webserver.
- https://www.patronuscharm.net
- https://blog.patronuscharm.net
- https://dev.patronuscharm.net
- https://www.darklordpotter.net
- https://forums.darklordpotter.net
Your browser will most likely complain about the SSL certificate, which is expected. The SSL certificate is self-signed. That doesn’t mean that it’s any less secure, SSL is SSL. What determines the security is your browser and the server, generally Firefox will use 256-bit AES encryption with SSLv3 and TLSv1. IE7 also offers the same encryption, though IE6 only has 128-bit encryption. For DLP and PatronusCharm, this hardly matters. The point being is that no matter who the certificate comes from, it’s still encrypted. What SSL certificate brokers offer is a guarantee that they’ve verified who is behind the site. Depending on the certificate class, with 1 being the lowest and 3 being the highest (plus extended verification, which includes background checks), more verification of the entity behind the certificate and generally offer a certain amount of guarantee financially if the encryption fails or the entity is false.
Well, this started as a notification of DLP/PC both having SSL urls and it turned into a lesson on packet sniffing, SSL, and SSL certificates. In conclusion, use those URLs to secure your transactions with DLP. I know I’ll be using them while surfing from college this upcoming term.
One Response to “SSL and DLP: Little Known Secret”
Heya Raven, I love this new dev blog, keep it up!
By Gizmore on Jul 1, 2008