SSL/TLS

[lpoulain]

All,

Having implemented a (somewhat) working TLS client (Transport Layer Security, NOT Thread Local Storage), I am ready to write a Wiki entry about it.

I just wanted to confirm this is a proper topic for the osdev.org Wiki and not considered too high level.

[SpyderTL]

I think this is a great idea. I'd also love to have a wiki page for HTTPS that's readable and simple enough to understand the basics. Pretty much everything nowadays uses SSL/TLS, so an OS is pretty useless without it.

[lpoulain]

I've posted the first draft: http://wiki.osdev.org/SSL/TLS

I hope it is clear enough - TLS is everything but simple.

[Combuster]

There seems to be some confusion as to what public/private/shared keys mean in common terminology.

Private key
Symmetric encryption

That's a shared key, or quite often just "key". A private key basically implies there's a public key.

The server sends a Server Key Exchange message, initiating the key exchange and signing it with its public key

You always use your private key, or his public key with asymmetric encryption. You don't (shouldn't?) have his private key, and conversely using your own public key has no use other than sending messages to yourself alone.


There are many errors like these, but shared keys being called private keys is by far the most common.

[lpoulain]

I did hear the use of the term private key for symmetric encryption. But I can use another term such as "secret key"

[Solar]

(Not having read the article, just clarifying for the thread's sake.)

Symmetric encryption means you use the same key for encryption and decryption. The (one, singular) key gets known, your encryption is broken.

Asymmetric encryption means you have two keys. Whatever is encoded with one can only be decoded with the other, and vice versa.

With asymmetric encryption, you can afford to make one of the two keys "public", keeping the other "private". Whoever wants to send you a secret message encrypts it with the (readily accessable) public key, and only you (having the private key) can decrypt the message. Likewise, you can encrypt a hash of your message using your private key, which everybody can then use to check this message is actually coming from you: If decrypting the signature with your public key yields the correct hash, the message was signed by you. (Everybody could have calculated the hash, but only you could have encrypted it with your private key.)

[lpoulain]

I have been working on this wiki for a couple of weeks now, and I think it looks pretty good, as it is now covering how to implement the most common cipher suites.

[embryo2]

I've missed this topic, but it's really interesting.

I've read the article and most important issue (at least for me) is the lack of a general framework description, that can help to identify the OS parts where security is important.

First I see no security category in the OSDev Wiki. May be it should be a subcategory of the "Design Considerations". And as a design issue it should cover the whole body of security concerns for an OS. It should include the areas where security is important and it, in fact, is about information access, one branch of which is the remote data access over untrusted network. And one kind of such access is covered with the technology (set of algorithms and standards) called TLS.

And second - the security subject is quite large to be limited by TLS only, so it's important to fill the security category with at least basic information and kind of a road map for interested OSDevers.

Generally the information access can be split into two areas:

1. access authorization
2. minimizing impact of unauthorized access

The first area is about preventing unauthorized user from accessing the information. The second is about dealing with the cases where unauthorized access is unavoidable. The TLS and similar technologies are mostly important for the second area.

But OSDev Wiki needs more detailed categorization of the OS related security. So, who is ready to write the rest? Really important question

[lpoulain]

The (oversimplified) basics of security are pretty simple - no input shall be trusted and should always be sanitized. Applying them in practice is as hard as writing an OS without bugs. Even professionals like the guys who wrote OpenSSL created a huge vulnerability with Heartbleed.

Also, I'd be curious to know the level of interest in security on this site. In my experience, very few people want to spend the necessary resources on InfoSec. And when one's developing one's hobby OS, the goal may be more to have something working than something secure. I implemented TLS in my OS to understand how TLS works and to be able to access HTTPS-only Websites more than security.

That said, if there is interest in the matter I will gladly contribute with my knowledge.

[SpyderTL]

Great job, so far.

I would like to see examples in something other than Python, but I'll take what I can get.

Also, the parts that I'm most interested in are the Handshake section and the Key Exchange section. You might consider moving the encryption specific stuff to a separate page. Putting it all together makes my head hurt a little.

Maybe some examples showing the data inside of the packets being transmitted in both directions would be helpful, as well.

[lpoulain]

@SpyderTL: I can split into 3 sections: the general overview, the handshake and the encryption part.

As far as the Python code, the goal was to show more how the encryption is actually done. And yes, implementing modular exponentiation over 1024-bit integers in C/C++ is not easy, let alone Elliptic Curve or the Galois Counter Mode. That's why I provided details about the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite as it can be implemented in a low-level language like C relatively easily provided you use the hack I mention to avoid implementing modular exponentiation at the expense of security (great first step even if you eventually want to build something secure)

[SpyderTL]

@SpyderTL: I can split into 3 sections: the general overview, the handshake and the encryption part.

As far as the Python code, the goal was to show more how the encryption is actually done. And yes, implementing modular exponentiation over 1024-bit integers in C/C++ is not easy, let alone Elliptic Curve or the Galois Counter Mode. That's why I provided details about the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite as it can be implemented in a low-level language like C relatively easily provided you use the hack I mention to avoid implementing modular exponentiation at the expense of security (great first step even if you eventually want to build something secure)

I've highlighted the words above that I actually understand.

I think that the technical byte-by-byte packet definition of the SSL standard(s) deserves it's own page, so that I can work on that code independently of the "pluggable" encryption methods used by the keys.

I understand that you understand how it all fits together, but someone just starting in OS Development or Network Security is going to have a hard time picking it apart.

Once I have it organized and written down in a way that makes sense to me, I can add some Wiki pages to try to help out some of the new guys, but it will probably be a while before I get to that point. And it would save me the trouble if you understand it well enough to separate it out, yourself.

(For instance, the page does not mention the valid values for the content type field of the SSL header, nor does it describe any of the structs for the different content types)

[lpoulain]

I've split the page into 3. I will also work on adding more details about the TLS packets. But the best way to understand how they are formed is to examine at a TLS communication using Wireshark.

[lpoulain]

By the way, we can have a Google Hangout if you want to go over how to use Wireshark and understand more how TLS is working.

[embryo2]

The (oversimplified) basics of security are pretty simple - no input shall be trusted and should always be sanitized.

But you should understand why it is required to sanitize everything. And understanding can tell you that sanitizing alone is not secure. For example - internet access is performed using untrusted intermediaries, so what can you sanitize when somebody just copies your data on the fly?

Security is about data access constraints. And you can prevent just some types of data access by sanitizing everything. First - you should plan what do you want hide and why. Next you can decide on the method. If you want to hide your site administrator console then may be it's enough just not to tell everybody the exact path part of the site's URL where the console is available. But if you think somebody can intercept your packets and find the path then it's better to encrypt the console access. Next question is about what algorithm to select for the encryption. Here you should understand the weaknesses of the algorithms you are going to select from. And one problem (among many, of course) is to prevent somebody else from using your secure connection instead of you. That's why you should sanitize the input of your site's administrator console. But without things to hide, the hiding method, interaction media, encryption and many other parts the sanitizing is just useless.

Applying them in practice is as hard as writing an OS without bugs. Even professionals like the guys who wrote OpenSSL created a huge vulnerability with Heartbleed.

It's about the "why" part of the equation. Why should many beginners be bothered with the security?

Also, I'd be curious to know the level of interest in security on this site.

The OSes here mostly are for learning, so, the security is also can be viewed as a part of the learning process. Just like is the case with you:

I implemented TLS in my OS to understand how TLS works and to be able to access HTTPS-only Websites more than security.