Archive for category Networking

Stenaline Public Wifi Very Insecure – SSL MITM Attacks

Update: Stenaline have responded and disabled email inspection

Fabulous, they have disabled the configuration that was causing me the most problems, within 24hrs of my original post. Congratulations stena line and I look forward to my return journey!

As a direct action on your mail we immediately notified our service provider regarding this issue and the problem is now located and solved.

IMAP protocol inspection is now disabled. The previous setting was an unintentional mistake by our service provider. .

Original Post:

Stena Line provide free wifi, which is awesome, however, their egregious content filtering system massively compromises the passengers online safety far more than normal public wifi hotspots.

They claim on their captive portal login screen on their on-ship wifi:


Privacy protection
All open wireless networks are by nature insecure. Please, take the necessary precautions to protect your privacy and data communications.

What kind of security, does the network provide?
The network security level is basically the same as you find on public hotspots.

However, this is clearly not the case, because they go out of their way to invalidate “the necessary precautions” that I normally take which is checking my email over SSL protected connections..

It appears stenaline think that its OK for them to snoop on my SSL secured private and work emails some fortinet/fortigate snooping appliance they seem to have. This appliance proxies SSL connections and re-signs the certificates with its own keys, effectively performing an SSL MITM (Man In The Middle) Attack. SSL is designed to prevent this sort of thing, which is why your browser throws up an error message when somethings gone wrong. All in all, this however means nobody can tell if its them “protecting” me or if it is infact a rogue hacker running a fake access point, a so called “Evil Twin” network, collecting peoples google, and corporate credentials, or snooping on my emails.. Thanks very much guys.

Update: It appears that It’s not limited to email or non-https web ports, lots of websites that have https connections blow up too, even common ones like google plus which loads content from (a google owned site). They appear to whitelist certain popular websites to allow https directly, but this is unmanageable and unmaintainable, and wholly ridiculous. I cant safely sign into my work SSL VPN with this either.

Heres an example where they have stripped the regular CA and added the Self-Signed Fortinet CA Certificate for

$ openssl s_client -connect
depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FortiGate CA, emailAddress =
verify error:num=19:self signed certificate in certificate chain
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/
i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=FortiGate CA/
1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=FortiGate CA/
i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=FortiGate CA/
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/
issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=FortiGate CA/

it should look like

$ openssl s_client -connect -showcerts
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/
   i:/C=US/O=Google Inc/CN=Google Internet Authority
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/
issuer=/C=US/O=Google Inc/CN=Google Internet Authority

All in all, the standard advice of when using a public wifi connection, use a VPN still stands…

As most regular folk dont have a VPN (and even SSL VPNs are compromised here), the best you can hope for is that the sites you use will use SSL, and that you dont just willy-nilly click “OK” on Browser SSL Warning Pages, sadly, this standard web-safety advice means you just cant browse the web safely on stena line ferries.

Google take a very dim view on this sort of thing: Google security blog: Attempted man in the middle attacks

Another interesting thing is that this may also be illegal in the UK within the terms of the computer misuse act or telecommunication acts, as they are attempting to decrypt an encrypted communication, though I’m not a lawyer. If anyone can shed any light on this I’d like to know.

I’ve emailed stena a link to this post to see if they respond, and hopefully set a timeframe for removing this egregious device/configuration from their network.

No Comments

How to get rid of GPG NO_PUBKEY errors when doing apt-get update

When doing apt-get update you might see a lot of errors like

W: GPG error: lenny Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY DA4420ED288995C8
W: GPG error: Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 85753AA5EEFEFDE9
W: GPG error: karmic Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 28577FE31F882273
W: GPG error: lenny Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 54422A4B98AB5139

For the best part you should install the apropriate keyrings

apt-cache search keyring$

should list most of them, sometimes they dont exist for some third party repositories, so try this one liner, split for (a little) clarity

for KEY in `apt-get update 2>&1 |grep NO_PUBKEY|awk  '{print $NF}'`; do
 gpg --keyserver --recv $KEY; gpg --export --armor $KEY|apt-key add -;

Caveat, this is insecure, but more secure than disabling validation. Please be aware for full security you should validate the key signatures you are importing via private quantumly secured links to the originator obtained at your own cost, etc etc.


1 Comment

Validating and Exploring DNSSEC with dig

Now that the Root DNS nameservers and .org TLD have both been signed, you can validate DNS server responses are legitimate.

In an attempt to learn better how this all hangs together, I thought I’d first try and validate some requests.

My first difficulty was figuring out what the root nameserver key is, what format it needs to be in, where you store it, and how to use it with dig to validate. Of course, the keys themselves are stored in DNS, you can query them in the format DIG needs to read them back with the command:

dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key

This can be placed in /etc/trusted-key.key if desired for site-wide dig use, or else it will search the current directory for it.

If the file cannot be parsed, dig when you try to use it in dnssec mode will print:

No trusted keys present
;; No trusted key, +sigchase option is disabled

To test out a full chain of validation from the root, you can now try to resolve

dig +topdown +sigchase +multiline -ta

-- snip --

;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for with DNSKEY:12892: success
;; VERIFYING A RRset for with DNSKEY:7617: success
;; The Answer:		600 IN A

;; FINISH : we have validate the DNSSEC chain of trust: SUCCESS

Hooray, we have validation.

No Comments

Blog is now IPv6 Enabled

Although my awesome hosting company dreamhost are not serving up via IPv6 yet, I’ve IPv6 enabled by blog for them by using apache reverse proxy on my home machine.

I configured apache much like: with a few differences

1. I didnt use NameVirtualHost, just put a specific IP in. NameVirtualHosts just feel a bit unnecessary with IPv6, and this way i can point several aliases at the entry without defining them all. This may be considered a small security issue, as other people could point their illegitimate domain names at your site and it would still work and look official.

2. So i didnt have to register all of the aliases, i did not enable ProxyPreserveHost

3. As would resolve to AAAA and A, I didn’t want Apache to get in a loop and proxy to itself, so i added an alias v4 to ensure v4 only forwarding.

For some reason it was sending 301 redirects until the DNS was all sorted

# Contents of /etc/apache2/sites-available/
<VirtualHost [2001:470:9272:1::2]>
 CustomLog /var/log/apache2/ combined

 ProxyRequests Off
 Order deny,allow
 Allow from all
 ProxyPass             /
 ProxyPassReverse      /

Also added the IP address to my /etc/network/interfaces so it would get allocated when the tunnel came up, by adding the following line to my tunnel interface stanza:

up ip addr add 2001:470:9272:1::2/64 dev $IFACE preferred_lft 0

The preferred_lft 0 is to mark the ip as deprecated so it doesn’t get used as the default address for outgoing connections. For more information see:

No Comments

Debian IPv6 Configuration and Lessons Learned

I’ve had a few issues configuring IPv6 on Debian

If due to a misconfiguration a v4tunnel interface you have brought up with ifup has failed, you need to manually delete it before trying again or this annoying error will happen:

# ifup somev6tunnel
ioctl: No buffer space available
# ip tunnel del somev6tunnel
# ifup somev6tunnel

I was trying to configure a 6to4 tunnel but without specifying a local interface address by using local any endpoint any, but that gives an unhelpful and yet increasingly familiar error message.

# ifup 6to4
ioctl: No buffer space available

Linux doesn’t like both local and remote values unset, so I thought, aha I’ll just use local any endpoint, it appeared to work. I have since realised that it only works for talking to non 6to4 hosts, if I tried to talk to another 6to4 host, it routed the packets through the gateway instead of directly and the return packets were also lost. So, I just specified the local address and it works.

My working 6to4 debian /etc/network/interfaces

auto 6to4
iface 6to4 inet6 v4tunnel
address 2002:561e:XXXX::1 # ipv6calc -I ipv4addr -O ipv6addr -A conv6to4 86.30.XX.XX
netmask 16
local # address assigned by wifi router
endpoint any
gateway :: # 6to4 anycast address

Though its best to use a managed tunnel, like Hurricane Electrics

The is the Debian network interfaces config i used to connect to my ipv6 tunnel, reconfigure the tunnel endpoint dynamically, and also add one of my routed /48 subnets to the interface (so i can use pretty reverse dns addresses from my host).

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:1f08:xxxx::2
netmask 64
gateway ::
# Docs to generate pass etc from
up wget --no-check-certificate -O - '' 2>/dev/null
up ip addr add 2001:470:XXXX:1::1/64 dev $IFACE


No Comments