Recently, we encountered a interesting bug on one of our multi-platform app development projects: an older Android (4.1) client was quietly failing to connect to the backend API. Upon checking the server logs, we discovered the cryptic error: “SSL Handshake Failure.” Oh boy.

We rarely run into low-level errors of this nature since we usually build our applications on a Platform as a Service (PaaS). Part of the allure of using a PaaS on this and other projects is that we get to delegate our infrastructure needs to the platform, which frees us up to focus on developing the applications themselves. Encountering this type of error has an upside, though: it’s a good opportunity to peel back some abstraction layers, learn a bit more about the underlying server infrastructure of our app, and (my personal favorite) employ the bug hammer.

Secret (SSL) Handshake: Explained

The first question: what exactly is a SSL handshake? Well, it’s the series of negotiation steps to establish a secure connection between two computing devices.

1. One computing device acts as the client and contacts the device acting as the server.
2. The client starts by sending a message to the server about its connection capabilities: the latest version of connection protocol (e.g. TLSv1.0) it supports, and a list of compression algorithms and cipher suites—named sets of algorithms used during the handshake process.
3. The server replies with its certificate, public key, and a protocol and cipher suite from its own compatibility list that match the best capabilities of the client.
4. Using the agreed-upon protocol and cipher suite, the client replies with an encrypted message that only the server can decrypt with its private key.
5. Since the client and server now have the same message, they each use that message to generate a master secret, and use that master secret to produce and verify symmetric keys for quickly encrypting and decrypting exchanged data during the connection.

Okay, now we understand the handshake steps, but we’re still not sure when exactly the failure is occurring. Let’s start with the first half of the handshake: agreeing upon the best possible connection protocol and cipher suite. In our PaaS’ configuration, there’s a single flag to toggle subsets of allowed SSL protocols and cipher suites. After adjusting it to the most permissive setting, we observe that our older Android client can connect. Hurray! But wait, what’s the root cause? And is this a good solution?

Rummaging Through the Toolbox

In the case of our PaaS, there wasn’t good documentation around the effects of this configuration toggle. So how do we introspect about the SSL capabilities of the server? There are a few tool options, but I leaned on these two: nmap on the command line, and SSL Server Test by Qualys SSL Labs on the web. Both tools give you a list of the supported protocols and cipher suites, but SSL Server Test also tests your server against a variety of clients and rates the security of your server in terms of common SSL vulnerabilities.

Running nmap against a host outputs a result that looks like this:

Running SSL Server Test gives you a report that looks like this:

Light at the End of the Debugging Tunnel

When we configure our server to the most permissive setting and run nmap¹, we see SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 as the supported protocols. When we toggle this setting, we see SSLv3 disappear from the list. And for good reason: SSLv3 is considered “fundamentally insecure” due to its vulnerability to attack and inability to support strong cipher suites (RFC 7525). But it would appear that our older Android client is relying on this protocol to connect.

Aha! We’ve gotten to the root cause of the problem and even found a very simple fix. However, is this solution the right one? Completely securing an application that exists on the open web is next to impossible. Rather, we strive to minimize the attack surface of our applications—that is, we aim to develop software that has the fewest and most difficult to exploit vulnerabilities. Enabling SSLv3 on our server would run counter to that goal.

With this in mind, the better solution is to configure our client device to use a more secure protocol. In the case of an Android 4.x device, though all protocols are supported, only SSLv3 and TLSv1.0 are enabled by default (Android SSLSocket docs). So to finally squash the bug, our Android developers wrote a custom connection specification to enable the newer protocols and cipher suites.

Conclusion, or Dreaming of a Perfect Abstraction

Using a Platform as a Service is a wonderful abstraction that enables us as developers to not worry about the infrastructural “plumbing” of our apps. But sometimes that plumbing–ahem–abstraction springs a leak, and requires us to go investigating in lesser-known territory. Luckily (for the sake of developer morale), the components underlying the abstraction aren’t scarily opaque, and, as we’ve seen, there’s a rich toolset to leverage when solving problems at this level of your application architecture. So grab your galoshes and bug hammer, and go boldly in search of a fix.

The post Computers Like Firm (SSL) Handshakes Too appeared first on Big Nerd Ranch.

Phillip interned with Big Nerd Ranch as a backend developer in 2015 and was hired as a permanent employee after the internship. In this interview he describes his journey from non-developer to Nerd.

What was your background in programming before the internship?

Way far back, I remember programming my scientific calculator in high school. Around the same tine, I took a half-semester of C++. I loved it, but then I totally forgot about it.

Fast-forward to 2014, and I was working as a chemist in a manufacturing lab. The job was pretty repetitive, so I started to dabble in programming as a kind of brain exercise. I picked up Python while taking a MOOC (massive open online class), and started to tinker on my own and with some new friends in CodeNewbie (shoutout to Python Thursday and that wonderful community of folks learning to code!). After that I discovered code katas: small scale puzzles basically asking “write a method that will do X.” I love puzzles, so that really got me hooked.

I learned a little Ruby syntax to apply for a Ruby bootcamp scholarship. I didn’t end up getting the scholarship, but I went to a RailsBridge event soon after and that cemented my interest in Ruby.

What got you interested in interning at Big Nerd Ranch?

I had been brainstorming what the next step could be toward becoming a full-time developer. Bootcamps are expensive, so I wanted to see if I could learn enough on my own to get an internship or apprenticeship instead. The only time I had been able to put toward studying and learning was a year’s worth of spare time, so I felt like an internship was sort of a long shot, but I kept an ear out.

Someone posted in a Slack group I was in about the backend internship at Big Nerd Ranch. I took a look at the internship description and Big Nerd Ranch’s web site and I was interested!

How did the internship help you grow as a developer?

There were a few different dimensions the internship helped me grow in. Technically, I learned Rails, became more comfortable in Ruby, and practiced solving problems in Ruby. There was also the dimension of code-adjacent tools: I learned more about using Git for version control, Pivotal Tracker for feature management, and other tools for collaborating around code. Finally, there was the value of experience. There’s no substitute for working on a real client-facing project, whether that’s an intern project for internal stakeholders, or a client project for external stakeholders.

What about the internship was most surprising to you?

When you aren’t using your brain for anything strenuous most of the day, and programming is an outlet to engage your brain during off-hours, switching to engage your mind full-time in that way is surprisingly tiring. Not to mention that when you’re starting out, there are a few things you know and a bunch of things you don’t know. You’re trying to connect as much of what you don’t know into what you do know, and move concepts and ideas into to the known and understood “pile”.

At one point, I had a conversation with my internship mentor about the idea of pushing the framework to the boundaries of your code and focusing on your domain problems, and it broke my mind. Up until that point, I had been thinking entirely in terms of learning the framework and writing Rails code, and that was the moment that I realized Rails is just the tip of the iceberg!

How did you decide you wanted to stay at Big Nerd Ranch as a permanent employee?

I had gotten the advice that as a new developer one of the most important things you can do is optimize for learning. You’re still discovering habits and ways of thinking. Since you’re a (relatively) blank slate, it’s to your advantage to work at a place where people are focused on best practices. And Big Nerd Ranch is definitely one of those places. People with development experience elsewhere come to work here because it’s a respite, a place where people are focused on doing things right.

I’ve realized that one important facet of optimizing for learning is to leverage the powerful ability of your brain to pattern-match. For example, if you’re learning to write essays and all you read is cartoons, your essays will be cartoonlike. But if you spend a lot of time looking at examples of great essays, your own essays will improve. Working at Big Nerd Ranch is a way for me to have access to great code so that I can then, in turn, do my best to produce great code.

What advice would you give someone thinking about a programming internship?

The beautiful thing about an internship is that you have the time to focus on one thing 100% of the time. There’s no substitute for calendar time. An internship is also an investment in your learning. If you’re thinking about career switching, there’s an opportunity cost in foregoing the things you could otherwise be doing. But investing in your learning will always pay dividends.
Another benefit of an internship is that it’s a rare opportunity where questions are encouraged and you can lean on your inexperience to get explanations for anything.

I’d recommend setting yourself up to absorb as much context as possible: maximize your opportunities to learn new things. Go to a talk on a technology you don’t know much about. Listen to podcasts and hear what other people in the community are thinking about. Browse the headlines on tech news sites to get a sense of what tools and technologies people are excited about. As a new developer you’ll mostly focus on one area, but take some time to be aware of surrounding areas as well. If nothing else, this will help guide your learning path once you’re finished with the primary area you’re focused on.

Finally, the narrative you tell yourself as a junior developer is also really important. If it’s a little fearful, if you tell yourself “I’ve gotten this far, but I’m not sure about it——it might be a fluke,” then you hamstring yourself. It colors the code you write, your interactions with your team and coworkers, and it hampers building your confidence as a developer. Be kind to yourself; tell yourself you have made progress and that shows you will be able to become a great developer!

Want to experience a Big Nerd Ranch internship yourself? Applications are open for summer 2017 internships for web development, mobile development, and design. Apply today!

The post Becoming a Nerd: One Developer’s Journey appeared first on Big Nerd Ranch.