The problem with SNI (and domain fronting) - Heisenberg's SNI?

HTTPS/TLS means that a browser or app or client can access a website or other resource over an encrypted link.

Now, the way this usually works is things like https://aa.net.uk/ where the browser makes a connection and as part of that connection its says it wants aa.net.uk so the server knows to serve the certificate and key for aa.net.uk.

The problem is that the name of the service (SNI) is in the clear and so some censorship systems can spot this and block it.

Now, we have some generic hosting environments. Cloud services. The nice thing is they have loads of IP addresses for all sorts, so hard to block.

Domain fronting fools this but sending a different SNI (asking for a specific certificate, in the clear) that is "OK" and then talking to a server that is not the same as the SNI.

This fools censorship systems.

Some cloud services are blocking "domain fronting" like this (why?).

OK this is hard to explain... We could do SNI after DH logic, making it so the service you want is encrypted. But as that is before you authenticate (as you cannot authenticate yet as that depends on SNI) it could be "man in the middle" but if it is then the next step of authenticating will fail.

It is like Heisenberg - you can either see what "domain name" is being requested, or you allow the connection, one or the other.

So the logic is simplified - your have two choices :-

• You can detect what someone is accessing (see the SNI)
• You can allow a connection to work

Basically no way to detect it and allow it to work. It is one or the other, only!

Does TLSv1.3 do this, I have not checked. If not then maybe TLSv1.4 will.

Clearly this is possible, and necessary, ASAP. It seems a real shame to me that the SNI was ever "in the clear".

FB2900 and Let's Encrypt

Well, the FB2900 is out!

The retail prices are lower than the old FB2700, £500+VAT for base, and £550+VAT for fully loaded with £35+VAT for rack mount kit. We should have the DC powered models available soon.

We have gone for lower prices to encourage more take up in the SME market. It is a bit of a gamble, but this is a really good product - not just a gateway router handling multiple ISPs, but even a VoIP switch / PABX. Perfect for most small businesses and even some large businesses.

The delay, for a week or so, was down to wanting to ensure https was working - this meant a lot of loading Windows VMs and testing on all sorts of different browsers. It needs manual loading of key pair and cert but it works well. I am really impressed with the work of my colleague, Cliff, on this, as the end result is just as fast to use as http. Very impressed.

It is timely as safari, and I am sure others, are now getting quite pushy on sending any form to a site not using https.

But we have said we expect to release more new code soon. The FireBrick s/w has always been free, and we have ensured the older models FB2500, FB2700 and the FB6000 series, all have the update for https now. But the next code issue should make it a lot cooler.

First off, I am planning some simple self signed stuff so you can use https before setting anything up. This is a bit naff, but every other idea we have come up with has flaws, and it is what everyone else does. The key thing is that it stops passive snooping as a threat, but not not proper security.

You need a proper key pair, and certificate, to do https without warnings. The FB2900 have a key pair loaded individually as part of the production process which means we just need a certificate. The FB2500, FB2700 and FB6000 series will need a key pair loading. This is partly because we are not yet confident we can make a "good" key pair. We are very cautious when it comes to security, and this is an area that has gone wrong for others, so we want to be careful. When we are happy we can, we will, but whilst FB2900 has a hardware true random number generator, the older models do not, so it will not really help for non FB2900s.

But even with a key pair loaded, which is not hard, you need a certificate. This is where we plan to do way better than most embedded systems. We plan to use ACME with Let's Encrypt as standard!

So the idea is simple, tell the FireBrick its public hostname (and if not an FB2900 then load a key pair) and it will make a CSR, apply for a certificate from Let's Encrypt and install it and renew it as needed. Proper working https with no warnings and no faffing about renewing things. That's the plan.

The same certificates and keys can then be used for IPsec, obviously.

It is not that easy as it is aimed more at a traditional machine / server, and not an embedded device, but I believe we should be able to do that within a few weeks and have a new s/w release.

In the mean time, do enjoy the new s/w release for the whole range - which will be a formal release shortly after beta testers are done with it.

P.S. (18th April) All going well, and we expect to issue alpha code any day. Test bricks with just adding public host name working on https 4 seconds later. This is "fun" coding!

FireBrick FB2900

FireBricks have been around nearly two decades now, before things like https were a consideration. Whilst we have embraced IPv6 as part of the design of the current FireBricks from the start, https was not top of the list. Why? Well, the FireBrick web interface is usually only for management of the FireBrick. The idea is that most customers would have it is on a separate management LAN, or locally connected, of even behind an IPsec tunnel (which the FireBrick can do), so https was not actually needed that much.

However, https is more and more a thing and becoming so much the normal way of working (with browsers warning if not https even), so we are including it in the new FB2900, and the existing FB2500, FB2700, and FB6000 series as a free software upgrade.

In fact, working https, with an SSL Labs score of at least "A", is pretty much the reason for the current delay on the FB2900 launch. We have finally sorted the other issues which had added months and months to the launch of the FB2900, but as https is almost ready we are going to ensure the launch has https. It is literally a matter of days away - I have working https on my test FireBrick (SSL labs score "B") even now, thanks to hard work of my colleague Cliff.

We then follow on with ssh, and the plan is ACME support to use Let's Encrypt to make https really easy to install - point a domain/hostname at the brick's IP and bingo, it will be properly certified https. It will still have all of the access controls, but with caveats for ACME certificate renewals. The ACME Let's Encrypt certificates will help with IPsec configurations as well.

Sadly, one of the things we would have loved to do is impossible. We wanted a brick "out of the box" to work with https with no warnings. We could maybe include a cert for my.firebrick.uk or some variant to do this, but any means by which a FireBrick has a private key in the code would mean someone could get a FireBrick and JTAG or some such to extract it from the flash. It would allow that key to be extracted and misused. The only real answer will be for a FireBrick to have a unique key pair and obtain a signed certificate by ACME, or similar, and that can only happen after it has a public hostname and internet connection. So the initial set up will have to be over http or with a "security exception" to talk https. Typically this is literally a laptop connected to the FireBrick, so either is acceptable, but a shame no way to avoid that. It would be interesting to consider the ways embedded devices could solve that within an https and certificate framework one day (TTL 1 and tied to MAC address or something?).

So, FB2900 really close now... Many boxes on the shelves ready to ship... Watch this space!

P.S. I won't bore you with the days of work on the outer packaging shipping label featured in the image above. Lots of svg, barcodes, and postscript and stuff with UPCs and things. All very boring I am sure... :-)

P.P.S. We may forego the "A" rating at launch for the working on all main browsers and not add more delay.

P.P.P.S testers that can load "alpha" releases should hopefully have access to play with this in next day or so.