Posts | Craig Hesling

Insecure Temp WiFi Networks

Mon, 04 Feb 2019 14:06:12 -0500

Introduction of Problem

After traveling to SF and connecting to numerous free WiFi networks, I have returned back to Pittsburgh and realized that my laptop still likes to connect to unsecured xfinitywifi over my normal house network. This would be the same deal if my laptop happen to see another insecure network named SFO-AIRPORT-FREE-WIFI or the hotel’s free WiFi network.

I understand that I could drop the connection priority of these insecure/free networks in the network manager, but it still exposes a human centric security flaw.

The concern is that, by default, the Gnome network manager places newly connected WiFi network at the top of the preferred networks priority list. So, if your laptop sees these newly connected networks in the same vicinity as your older home network, they connect to the temporary network instead of your trusted home network. This wouldn’t be a serious issue if it weren’t for the fact that these temporary networks do not require any authentication. Anyone can create a network with the same name and no authentication and BOOM, your laptop connects.

TL;DR

I will just jump right to my point. I feel you should have an easy option to specify an expiration for a WiFi network, on connection. The purpose would be to make sure your laptop will not connect to it after your trip or outing to Starbucks.

An even easier half-way solution, would be to automatically drop the priority of insecure networks to the very lowest. The hope is that you laptop would always prefer you secure authenticated networks over a rouge insecure network, although I suspect this may not always be the case.

Accidental Experiment

I have been more cognizant of this issue ever since my little accidental experiment.

While on campus, I configured a RaspberryPi to connect to my school’s insecure WiFi network named CMU. This was happening before the school offered their secure option called CMU-SECURE. I was never a fan of lugging around a monitor+keyboard, so I would interact with the Pi over ssh. I then returned home and realized that I hadn’t configured it with my home WiFi network. At the moment, I really didn’t feel like grabbing a monitor+keyboard or ripping out the SD card to write a new network. So, I simply created a guest WiFi network named CMU, so that it would just connect. The plan was to have it connect and then add my WiFi network to the wpa_supplicant.conf. It worked perfectly, but one might say that it worked a bit too well.

I found the RPi’s IP in the DHCP Lease log, but I also found tons of other mysterious devices that I hadn’t ever seen before. Since I live near many other CMU students, I immediately realized that my neighbors laptops had automatically jumped on my CMU network.

This obviously exposes an issue, where saved insecure networks can be used to grab traffic from unsuspecting devices. Not good! You might assume you traffic is broadcasted for anyone at Starbucks, but you assume it is safe(er) at your house.

We can fix this issue.

Call to action

Calling on all Gnome, Windows, Android, and OSX developers.

Please add an option to make WiFi networks temporary and have expiration dates. It would be nice to check a box and specify an expiration date during the first connect stage.

At the very least, please make insecure networks the automatic lowest priority. If this already has a solution that I am not aware of, please comment below.

Let's Encrypt Root CA Cert

Sat, 13 Oct 2018 00:00:00 +0000

Overview / Explination

Since Let’s Encrypt’s own root certificate authority, ISRG Root X1, is still quite new and not commonly trusted. To get around this issue, Let’s Encrypt’s intermediate has be graciously cross-signed by IdentTrust’s root certificate authority DST Root CA X3, which is commonly trusted by clients.

What this means is that most certificates issued by Let’s Encrypt have an origin of trust from IdentTrust’s root CA.

Take for example the OpenChirp MQTT server. We can use openssl s_client to inspect the certificate presented to the user.

openssl s_client -connect mqtt.openchirp.io:8883

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mqtt.openchirp.io
verify return:1
---
Certificate chain
 0 s:/CN=mqtt.openchirp.io
 i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
...

The beginning of the output shows the root is CN = DST Root CA X3, which doesn’t look like Let’s Encrypt’s own ISRG Root X1.

So, if you need to present the root CA cert to some program (for verification), you need to present IdentTrust’s root CA cert. See the next section to learn how to grab a usable x509 PEM formatted cert.

Grab Cert and Convert

If we want to present the trusted root CA cert for a Let’s Encrypt issued certificate, we need to present the IdentTrust root CA cert. More specifically, we need to reference the TrustID X3 root cert. The only problem with this is that IdentTrust only offers their certificate in PKCS7 binary format (.p7b), which is unusable in a lot of reasonable applications. We need x509 PEM format.

The following instructions will show how to compose the x509 .pem file for the DST Root CA X3 cert.

TLDR

At the time of writing this, the following wget line was capable of grabbing the TrustID X3 cert in p7b format. The next openssl would convert that .p7b file to an x509 .pem file for normal use.

wget https://www.identrust.com/node/935 -O trustidrootx3_chain.p7b
openssl pkcs7 -inform DER -in trustidrootx3_chain.p7b -print_certs -outform PEM -out trustidrootx3_chain.pem

You can then use the trustidrootx3_chain.pem as the CAfile parameter of client programs.

Fallback Instructions

If the above commands failed, you can download the PKCS7 binary file (.p7b) file from the IdentTrust download page bellow.

To convert that PKCS7 binary file to x509 PEM, use the following openssl command:

openssl pkcs7 -inform DER -in <THE_DOWNLOADED_P7B_CERT> -print_certs -outform PEM -out trustidrootx3_chain.pem

You can then use the trustidrootx3_chain.pem as the CAfile parameter of client programs.

Example Usage of x509 PEM

Mosquitto Client

mosquitto_sub -v -i monitor$RANDOM -h mqtt.openchirp.io -p 8883 --cafile ./trustidrootx3_chain.pem -u <USER> -p <TOKEN>

GOBF

Fri, 04 May 2018 00:00:00 +0000

Intro

I have always been fascinated by compilers. I think the idea of representing one language’s structure inside of another language is just downright cool. Furthermore, the ability to analyze another language and optimize it really peaks my interest.

Recently, I worked on a project that would allow you to more precisely manage which processor core a set of Goroutines would run on. The idea was that Goroutines that communicate more than they process independently would benefit from sharing that same processor core’s cache. I called them M-Groups. The implementation called for modifying the runtime package and the Go scheduler. While ripping through the Go internals, I stumbled upon quite a bit of the Go compiler code, including the SSA library. As I ripped into it more, I started to form an itch to make my own compiler of some kind.

Fast forward a few months and I found myself staring at some examples of my favorite simple esoteric language, BF. BF is the perfect language to write a compiler / optimizer for because of its extremely minimal syntax. It only has 8 possible syntax items(called commands), <>+-.,[], but those simple syntax items quickly form complex programs (not in the sense of awesome functionality).

Here is Hello World in BF

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

GOBF Overview

Introducing GOBF, an interpreter/optimizer/compiler/code_generator for the BF language. It has two primary modes of operation, interpreting/running (as-is) and converting BF to optimized Go code.

Interpreting

Interpreting and running was the first mode of operation that really just served to solidify my understanding of the BF language. It simply sets up a virtual environment for the BF program and acts on each syntax item as they come. There is no optimization here.

Optimizing / Compiling

Next, I wanted to focus on how I would be able to generate super fast binaries from my BF programs. I considered lots of approaches, but the two most prominent ones were to directly assemble a binary from the BF commands and convert BF to equivalent Go code.

Directly assemble an x86 binary from the the BF commands seems like a natural extension, since BF forces the programmer to act somewhat like a state machine. The downside to this approach is that it would lack portability and would loose out on further architectural optimizations that are found in modern compilers.

I ultimately chose the ladder solution, where I convert the BF commands into equivalent Go code. Although it seems like a bulky implementation strategy, the program’s functionality is quite limited and we gain the builtin compiler inlining.

I have designed GOBF to parse BF programs and generate a internal intermediate representation(IR) that resembles a tree. The next major observation that BF contains lots of repetitive actions, like ++++++++, which increments the local accumulator eight times, only to save the value 8. These repetitive actions can easily be smashed into a single operation, which can yield massive speedups. The GOBF optimizer traverses the IR tree and coalesces these repetitive actions into a more descriptive single action.

When the optimizer finishes, GOBF generates Go code from the IR and optionally compiles it.

Benchmarking

I ran some of the typical BF programs you can find on the internet.

BF Program	Run Time
mandelbrot.b	8.162s
hanoi.b	5.401s
helloworld.b	0.003s

Running on an Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz

Future Work

I would like to create a reverse code generator that takes a high-level language, such as Go, and generates BF.

Links

GOBF on Github

Regenerate Chrome App/Extension Desktop Shortcuts

Wed, 20 Dec 2017 11:30:41 -0500

Table of Contents

Description

This is a quick how-to for regenerating the .desktop shortcuts associated with Google Chrome Apps or Extensions.

Rant

Being able to launch your favorite Chrome App/Extension straight from your desktop manager’s launcher is a big win in my book. My typical go-to is Google Keep. With my Gnome Shell setup, all I have to do is hit the Super key on my keyboard to bring up the searchable Gnome launcher, ever so slightly start typing k e e p, and pound the enter key. Presto, I’m in my notes taking app.

Every once in a while, a desktop shortcut disappears (possibly self inflicted) or becomes corrupt. The monotony of traversing through Chrome, to the Apps menu, and clicking on the correct App/Extension tile haunts me to this day.

This article is needed due to the dearth of information related to Chrome Extension desktop shortcuts for Linux desktop environments. I also needed a good tutorial to kickoff my Posts section.

Here is how to fix it

Method 1

Go to the All Apps page.

This is also the URL chrome://apps.
Right click on the App or Extension you wish to regenerate a shortcut for.
Click Create shortcuts...
Deselect Desktop, select Application menu, and click Create. A Desktop shortcut is pointless when you have Desktop icons disabled in Gnome Shell. [default for Gnome Shell]

Method 2

Press the three vertical dots in the top right of the browser.
Navigate to More tools and then Extensions
Click the Details linked text on the App or Extension you wish to regenerate a shortcut for.
Click Create shortcuts...
Deselect Desktop, select Application menu, and click Create. A Desktop shortcut is pointless when you have Desktop icons disabled in Gnome Shell. [default for Gnome Shell]

Unified Altium Components Library for Lab

Wed, 20 Dec 2017 11:30:41 -0500

Description

Within a lab group, there is need to standardize on footprints used, since it takes such a large amount of time to create the footprints to begin with.

https://github.com/WiseLabCMU/AltiumLib

Web Development

Wed, 13 Dec 2017 01:53:28 -0500

I’m really starting to get the hang of this web development thing. First Angular 1, then Angular 5, and now Hugo.

System Monitor Device (for OpenChirp)

Mon, 06 Nov 2017 00:00:00 +0000

Summary

How it works

Links

sysmonitor-device on Github

TI CC2538/CC26xx Serial Bootloader Utility on Linux

Tue, 11 Apr 2017 11:30:41 -0500

If you have ever been curious about using the TI CC2650 and other similar SimpleLink devices’ serial bootloader, wonder no longer.

I recently implemented the TI CC2538/CC26xx Serial Bootloader protocol in a Go library, called ccboot. This simply uses standard IO operations that can be used with a generic serial library.

Since a library is no fun without a command line interface, I have also implemented ccbootutil, which exposes most of the low level bootloader primitives(which can be shell scripted) and has a complete program sequence that reads ELF binaries, flashes, and resets the chip. You simply run the following command and ccbootutil did the rest:

cbootutil /dev/ttyUSB0 prgm YourCompiledProgramInStandardELFFormat.out

When implementing ccbootutil, I used a Go serial port interface library that indicated that it should work cross platform, so Windows and OSX users should not feel left out of the command line and scriptable goodness.

I have compiled the utility for each of the platforms in the repository builds/ directory.

Notes

I have found that the serial bootloader can flash the CC2650 faster than an XDS110 over cJTAG.
TI Smart RF Flash Programmer 2 certainly works, but is strictly for Windows and is not scriptable.

Links

Please let me know if you find any issues. Happy coding!