Watch A Web Page Fetch Itself Over TLS, Complete With Commentary

TLS, byte by byte performs an unusual and interesting function: it fetches itself over HTTPS, and provides a complete annotation of what’s going on in the process, one byte at a time. Visit the site and give the button a click to watch it happen, it’s neat!

Transport Layer Security (TLS) is what’s responsible for encrypting traffic over the internet, and it’s normally implemented on top of TCP to encrypt an application-layer protocol like HTTP (resulting in HTTPS and the little padlock icon in browsers indicating a connection with a web site is encrypted.) Back in the day, traffic over the internet was commonly unencrypted, but nowadays no communication or hardware is too humble for encryption and methods are easily accessible.

So for what purpose would someone actually need or use such an implementation of TLS? Well, probably no one actually needs it. But it is a userspace TLS implementation in javascript that may fit a niche for someone, and it certainly provides beautifully-indented and annotated binary data in the process. Sound up your alley? The GitHub repository for the project has all the details, so give it a look.

Squish That Stack With Rampart

[P B Richards] and [Aaron Flin] were bemoaning the resource hunger of modern JavaScript environments and planned to produce a system that was much stingier with memory and CPU, that would fit better on lower-end platforms. Think Nginx, NodeJS, and your flavour of database and how much resource that all needs to run properly. Now try wedge that lot onto a Raspberry Pi Zero. Well, they did, creating Rampart: a JavaScript-based complete stack development environment.

The usual web applications have lots of tricks to optimise for speed, but according to the developers, Rampart is still pretty fast. Its reason for existence is purely about resource usage, and looking at a screen grab, the Rampart HTTP server weighs in at less than 10 MB of RAM. It appears to support a decent slew of technologies, such as HTTPS, WebSockets, SQL search, REDIS, as well as various utility and OS functions, so shouldn’t be so lightweight as to make developing non-trivial applications too much work. One interesting point they make is that in making Rampart so frugal when deployed onto modern server farms it could be rather efficient. Anyway, it may be worth a look if you have a reasonable application to wedge onto a small platform.

We’ve seen many JavaScript runtimes over the years, like this recent effort, but there’s always room for one more.

Wireshark HTTPS Decryption

If you’ve done any network programming or hacking, you’ve probably used Wireshark. If you haven’t, then you certainly should. Wireshark lets you capture and analyze data flowing over a network — think of it as an oscilloscope for network traffic. However, by design, HTTPS traffic doesn’t give up its contents. Sure, you can see the packets, but you can’t read them — that’s one of the purposes of HTTPS is to prevent people snooping on your traffic from reading your data. But what if you are debugging your own code? You know what is supposed to be in the packet, but things aren’t working for some reason. Can you decrypt your own HTTPS traffic? The answer is yes and [rl1987] shows you how.

Don’t worry, though. This doesn’t let you snoop on anyone’s information. You need to share a key between the target browser or application and Wireshark. The method depends on the target applications like a browser writing out information about its keys. Chrome, Firefox, and other software that uses NSS/OpenSSL libraries will recognize an SSLKEYLOGFILE environment variable that will cause them to produce the correct output to a file you specify.

How you set this depends on your operating system, and that’s the bulk of the post is describing how to get the environment variable set on different operating systems. Wireshark understands the file created, so if you point it to the same file you are in business.

Of course, this also lets you creep on data the browser and plugins are sending which could be a good thing if you want to know what Google, Apple, or whoever is sending back to their home base using encrypted traffic.

Wireshark and helpers can do lots of things, even Bluetooth. If you just need to replay network data and not necessarily analyze it, you can do that, too.