Network

United Wifi and MITM attacks on TLS

So, I was going to check my Email to my private IMAPS (TLS, port 993) mail server. And I get this warning about the certificate from my mail client (Apple Mail). Curious, I checked the certificate, and found this:

Server certificate
subject=/C=US/ST=Colorado/L=Arvada/O=Ogre/CN=*.ogre.com/emailAddress=leif@ogre.com
issuer=/C=  /ST=Some-State/O=Blue Coat SG900 Series/OU=4312240020/CN=172.16.0.50
Now, this doesn't make a whole lot of sense. I know my certificate was not issued by this issuer. Who is that ? Well, Blue Coat SG900 is obviously a proxy of some sort, presumably a transparent (captive) proxy. But why would United care about my IMAP over TLS connection? What could they possible want to see? My email? Anti-virus? And, this is after I had paid the $8.99 (very reasonable) internet fees (so it should IMO not be captive any more).
 
Needless to say, I did not trust this certificate / MITM attack and therefore, unable to check my email. Very lame.

 

Note: This is the TLS handshake with the MITM proxy server:

Server certificate
subject=/C=US/ST=Colorado/L=Arvada/O=Ogre/CN=*.ogre.com/emailAddress=leif@ogre.com
issuer=/C=  /ST=Some-State/O=Blue Coat SG900 Series/OU=4312240020/CN=172.16.0.50
---
No client certificate CA names sent
---
SSL handshake has read 1754 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: XYZ
    Session-ID-ctx:
    Master-Key: XYZ
    Key-Arg   : None
    Start Time: 1397924326
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

Hacking: 

firewalld and network interfaces

I have to say, firewalld and firewalld-cmd really sucks. But, since it's the default on a bunch of installations I use, and I try to "drink the koolaid", I've had the misfortune to try to set it up. Now, it mostly works, except when it doesn't, and then it really fails hard. Case in point, I wanted to reassign some network interfaces to a different zone, and naïvely thought that e.g. this would work:

$ sudo firewall-cmd --permanent --zone=public --remove-interface=eth2
$ sudo firewall-cmd --permanent --zone=internal --add-interface=eth2

 

Yeah, not so much ... What does instead work is adding lines like this to /etc/sysconfig/network-scripts/ifcfg-eth2:

ZONE=internal

WTF?

Hacking: 

tmux and SSH agents

I use tmux a fair amount, together with iterm2's support for control channels, it's amazing. However, when restoring sessions, and you rely on SSH agents, it can sometimes get wonky. The issue being that the shell sessions under the tmux session loses the agent connectivity. So I wrote this little shell script, which I run as part of logging in and starting (or restoring) a tmux session:


#!/bin/sh
 
MY_AGENT=~/.ssh/.ssh-agent
rm -f $MY_AGENT
ln -s $SSH_AUTH_SOCK $MY_AGENT
export SSH_AUTH_SOCK="$MY_AGENT"
 
tmux has-session > /dev/null 2>&1
if [ 0 -eq $? ]; then
    exec tmux -CC attach
else
    exec tmux -CC
fi

 

It might not be perfect, I'm sure it could be automated better in some ways. But with this, naming the script "mux", I simply just run this command every time I want to connect to my tmux session. It'll figure out if it should attach to an existing session, or create a new one as well.

Hacking: 

Linux / Fedora Core and nf_conntrack:

While testing and benchmarking some new features in Apache Traffic Server on my dev box, I started having really odd problems with inconsistently lost connections or really slow performance. Upon examing the logs, I found a large number of kernel barf like

Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.
Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.
Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.
Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.

Clearly this could not be good. I poked around, and could not find any ways to turn off this kernel module, at least on my Fedora Core 13 it seems compiled straight into the kernel (i.e. no .ko). There are ways to increase the table size (sysctl's) but that seemed like a band aid at best. Bummer. So, I went to the mountain (Noah F.) and asked for advice. After some poking around, we found that forcing iptables to ignore the conntracking helps, a lot. E.g.

iptables -t raw -I OUTPUT -j NOTRACK

 seems to do the trick for my particular case. This turns it off for all protocols, but you could probably limit it further (e.g. for tcp only with a "-p tcp" option). Also, you might want to do this on the input as well, e.g.

iptables -t raw -I PREROUTING -j NOTRACK

We found this old report against Fedora Core 10 as well, which describes the same problem, but no solution.

Hacking: 

Haiku on VirtualBox and networking

I was playing around with Haiku (BeOS revival) under VirtualBox, and was trying to get networking going. To make a short story long, the "trick" is to pick a device to emulate other than the default in the VirtualBox setting. For me, the Intel Pro/1000T server works great, in the "bridged" mode at least. Cool!

Hacking: 

Pages

Subscribe to RSS - Network