Got my license
by Viktor Hansson on 08 May 2016, 08:28
I finally got my motorcycle license last wednesday! So now I've ridden for 2 days straight (got sick yesterday so no riding then), for a total of about 450km (279 miles).
Here are some pics I've taken
First motorcycle mod
by Viktor Hansson on 05 April 2016, 16:05
To quote the one and only Mr. Snowcat: Yoyoyoyoyo!
This weekend I finally got to ride my own bike out in traffic. Together with my father (can't ride alone yet :( )I drove the 20km out to Höllviken. Mostly fun twisting roads I'm quite happy with how the bike rides.
And last week I decided to install my first modification to the bike: a 12v outlet. Quite a simple mod, requiring only a little bit of understanding for electrical systems and the ability to read this instructable. It details every step of the process, as well as all the required material and tools. I bought all the material at Kjell, which came in at a total of 120SEK. Some extra wire and cabelshoes I already had.
Here's the relay loosely wired into the taillight plug, just to verify that it worked
By using a relay, the outlet is only powered when the ignition is on, which means the battery won't drain (hopefully).
This mod is mainly to be able to charge my phone when using it as a GPS, so next up is figuring out where I can mount the phone. With only clip-ons and not real handlebar this is a bit more challenging.
This weekend I finally got to ride my own bike out in traffic. Together with my father (can't ride alone yet :( )I drove the 20km out to Höllviken. Mostly fun twisting roads I'm quite happy with how the bike rides.
And last week I decided to install my first modification to the bike: a 12v outlet. Quite a simple mod, requiring only a little bit of understanding for electrical systems and the ability to read this instructable. It details every step of the process, as well as all the required material and tools. I bought all the material at Kjell, which came in at a total of 120SEK. Some extra wire and cabelshoes I already had.
Here's the relay loosely wired into the taillight plug, just to verify that it worked
By using a relay, the outlet is only powered when the ignition is on, which means the battery won't drain (hopefully).
This mod is mainly to be able to charge my phone when using it as a GPS, so next up is figuring out where I can mount the phone. With only clip-ons and not real handlebar this is a bit more challenging.
Mozilla Public Suffix List
by Viktor Hansson on 04 April 2016, 06:38
So last week I got a message from a collegue, saying that a production environment for a service provider was down. A temporary fix was for us to change our config and point to a backup site of the service provider. So we tried calling the backup site to make sure it was up, and everything looked fine. So we changed the config, but when our code made calls to the SP, we saw the following message in our logs:
After going home and eating dinner I did some more googling and discussed the issue with another collegue, and finally I found this issue with the apache httpclient, that stated that something called Mozilla Public Suffix List. This is a list of domain suffixes for which wildcard certificates should be considered invalid, like *.com ,*.se or *.tumblr.com, since otherwise theses certs could be used on literally all .com domains without as much as a warning. So checking the libs showed that we used httpclient 4.4, which checks this list when validating wildcard certificates. And after a search in the list, lo and behold *azurewebsites.net.
To verify that this was in fact the issue, my collegue compiled some code with first httpclient 4.4, which showed the error, and then with httpclient 4.3, which connected with no issue.
So in my mind the question is not how can we disable the MPSL, but instead how was someone able to obtain a valid certificate with a wildcard domain for a domain on the list...
javax.net.ssl.SSLPeerUnverifiedException: Host name 'foobar.azurewebsites.net' does not match the certificate subject provided by the peer (CN=*.azurewebsites.net)Since everyone at our company knows that I'm the "security guy", this was naturally bounced to me. My first instict was to check if the TLS implementation our code used even had support for wildcard domains in certificates. After some googling and answers of variyng quality I landed on the JSSE (Java Secure Socket Extension) documentation page and saw that wildcards were in fact supported. So then I figured it could be something strange with the SANs (Subject Alternate Name) on the certificate, but quickly proved this wrong be running:
openssl s_client -connect foobar.azurewebsites.net:443Then copying the certificate to a file and inspecting it with:
openssl x509 -text -noout -in cert.crtBut this showed that all seemed right with the cert at least. I got a message that the main production environment was up again so this was no longer an urgent matter, but it still eluded me as why the above message would be printed.
After going home and eating dinner I did some more googling and discussed the issue with another collegue, and finally I found this issue with the apache httpclient, that stated that something called Mozilla Public Suffix List. This is a list of domain suffixes for which wildcard certificates should be considered invalid, like *.com ,*.se or *.tumblr.com, since otherwise theses certs could be used on literally all .com domains without as much as a warning. So checking the libs showed that we used httpclient 4.4, which checks this list when validating wildcard certificates. And after a search in the list, lo and behold *azurewebsites.net.
To verify that this was in fact the issue, my collegue compiled some code with first httpclient 4.4, which showed the error, and then with httpclient 4.3, which connected with no issue.
So in my mind the question is not how can we disable the MPSL, but instead how was someone able to obtain a valid certificate with a wildcard domain for a domain on the list...
Internet Cryptography Part 2: Digital signatures
by Viktor Hansson on 26 November 2015, 22:29
- Previous part: Keys
- Next part:
Ok, so after reading the first part, you know know the difference between symmetric and asymmetric encryption. The next step is to learn about signatures. Not the insecure kind you use when signing for a package from UPS. No, digital signatures.
What is the point of a signature? It is to verify that the real you have been part of a transaction, whether that transaction is a binding contract, or just the delivery of a message. But your signature is actually the dumbest thing ever, since its extremely simple to reproduce, and for many of us, its not even the same on every document you sign. How a hand written signature can be legally binding is still beyond me.
But a digital signature works in a different way. Its based an asymmetric encryption. But to understand digital signatures, there is one concept you first need to know: Digest(Hash).
Digest (Hash)
A hash, or a digest, is a mathematical function which can be applied to a message, to produce an output that is a constant length, and which will not produce the same output for any messages that are not equal. That second part is something that people are still struggling with however. But the idea is that you have a message which can be any number of characters long, and when the hash function is applied on the message you get a string of X number of characters. This image may explain it a bit better
This can come in handy when you want to check if two messages are equal. Instead of comparing the entire message, you can compute the hash for each message and compare that.
This fact can also be used to verify that you get the correct message. For example: Bob writes a book, which is 2000 pages long, and he wants to send this book to Alice. They want to make sure that the book which Alice recieves is the exact book that Bob has written, not a single letter should have been changed. So Bob calculates the hash of the book, which results in a string of 30 characters. He then calls Alice and tells her this string. Now, he could just read her the book, since they know that they're talking to each other, and nobody else. But his would be very time consuming and boring. So insted, Bob just tells Alice to write down those 30 characters. He then sends the book to her and when Alice receives it, she calculates the hash of the book that she got. If the hash that Alice gets is the same as the hash Bob told her over the phone, then Alice can be certain that she has the exact same book that Bob sent.
So now you know what a hash is. Then how is this hash related to signatures you may wonder? Just hang on, we're getting to it.
See, there are three parts involved in a digital signature: a hash, a private key and a public key. So say Bob has written a message, which he needs to assure Alice that he is the author of. To do this, he signs the message. In practice this is quite simple.
When signing a message, you calculate the hash of the message. This hash is then encrypted using your private key (which you, and only you, are in possesion of, remember?). You then append the result (the encrypted hash) to the message. When the recipient receives the message, they need to verify the signature.
To verify a signature you first calculate the hash of the message. The next step is to decrypt the signature using the signers public key. Finally you compare the hash that you calculated with the one in the signature. If these are the same, then the message has not been changed. If they are not the same the message has been changed.
This image shows the process of sending a signed message and verifying it.
- Previous part: Keys
- Next part:
Internet Cryptography Part 1: Keys
by Viktor Hansson on 26 November 2015, 21:41
Lets just start from the absolute basics, and then work our way up to the actual tools for working with this stuff.
What is cryptography? Well, it's quite simple actually. Cryptography is the practice of securing a message, so that only the intended recipiant of the message can read it. An example would be that you write a letter describing the location of all your hidden gold which you need to send to your family. If you don't encrypt the letter, then the mailman could read it before delivering it, and then go and steal your precious gold.
What you need to know is that there are two types of encryption: symmetric and asymmetric. You don't need to understand how these types actually encrypt stuff, and neither do you need to understand why they're named as they are. But you do need to understand the difference between them.
Symmetric
Imagine a box with a lock. You need the key that fits the lock to actually unlock the box, but you also need the key to lock the box. And finally there is only one key that fits the lock. If we go back to the letter about the gold. One type of physical encryption would be to place the letter inside the box, and then mail the box. This way the mailman would not be able to read the letter.
This does however present another problem. How would your family unlock it, since you have the key? One way would be to meet them face to face and hand them a copy of the key. Then you know that there are only two keys, one for you to lock the box, and one for your family to unlock the box. But if you cannot meet face to face, then exchanging the key becomes more difficult. You could send it in the mail, but then the mailman could just make a copy of it before delivering it.
In this analogy the lockbox key represents the cryptographic key.
Asymmetric
Now imagine a different kind of lockbox. This has no built-in lock, but instead the ability to lock it with a padlock.
In this scenario, the first step is for your family to send an unlocked padlock to you, while they keep the key. Since the padlock by itself has no information which could be used to unlock it, it's safe to send it via the evil mailman. Once you get the padlock, you use it to lock the box containing the letter. The box is then sent to your family, at which point they can use the key to unlock it. This way there is only one key, and it never leaves the safety of your family home.
And in this analogy the key represents the private key, and the padlock is the public key. These two terms are going to be used heavily throughout the series.
Although there is one caveat to the above analogy. Where as a the padlock can be unlocked by anyone and only unlocked by the one posessing the key, both the private and public can be used to encrypt and decrypt. The public key can decrypt anything that has been encrypted by the private key, and vice verse.