6 ms·

Single C file TLS 1.2/1.3 implementation using tomcrypt

87 points by adulau 8y ago

cperciva 8y ago
I don't understand the fascination with "single file" libraries. Sure, you can take a well organized tree of a few dozen C files and turn it into a single ten-thousand-line monstrosity, but why on earth would you want to?
- skrebbel 8y ago
  I agree with you, but I guess you know that the answer is "because c still has no proper dependency manager so downloading a c file and adding it to the project/makefile/etc is often the easiest way forward"
  - tedunangst 8y ago
    Except it still depends on libtomcrypt.
    - skrebbel 8y ago
      Hah! Yeah ok :-)
- cjhanks 8y ago
  If you are working on embedded software in an environment without robust dependency management, dropping in a file is the easiest way to add a feature. You also may want to minimize symbol leakage into a C program, a single file allows most functions and constants to become static.
- throwaway12iii 8y ago
  It's very common in the C/C++ world. The main reason is that you can easily use it in other projects. Until one of the C/C++ package managers gets good and wins, this is the nicest alternative. Note that people don't necessarily develop the libraries in one big file or don't have dependencies. Many newer libraries use a single C file as a distribution format. The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. If it pulls in hundreds of thousands of lines of code, that can be a problem. Also, small code is a requirement on some projects because of speed or memory limitations.
  - black-tea 8y ago
    Yeah because it's really hard to include multiple files in another project...
  - frutiger 8y ago
    > The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. The size of the code is independent of the number of files the code is in.
- chrisseaton 8y ago
  It's very useful in some parts of CS research to have be able to bypass complex build and linking systems and just be able to run an instrumented C compiler of some sorts. I think it's also people giving up on build systems and package managers.
- simias 8y ago
  Because C has no package system and it sucks, and having a single file (ideally with no dependencies, which isn't the case here) makes it super easy to integrate it anywhere. A good example of that IMO is cJSON[1], it's a small self-contained single file implementation of a JSON reader and parser. It's easy to use, the code is pretty clean and easy to follow and I never ran into any obvious limitation. I very much recommend it. There are also projects that are developed as multiple files but amalgamated into a single huge file before release. SQLite does that: https://sqlite.org/amalgamation.html https://sqlite.org/amalgamation.html > Over 100 separate source files are concatenated into a single large files of C-code named "sqlite3.c" and called "the amalgamation". The amalgamation contains everything an application needs to embed SQLite. The amalgamation file is more than 220,000 lines long and over 7.5 megabytes in size (as of 2018-11-24). > Combining all the code for SQLite into one big file makes SQLite easier to deploy — there is just one file to keep track of. And because all code is in a single translation unit, compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster. [1] https://github.com/DaveGamble/cJSON https://github.com/DaveGamble/cJSON
  - peterwwillis 8y ago
    gcc -shared -o mycrypto.1.1.so file1.c file2.c file3.c file4.c #include "mycrypto.1.1.h" Doesn't that have the same effect of being easy to include? The amalgamation may be better for the compiler but I'm not sure why.
    - tialaramex 8y ago
      A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work. But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster. Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.
- flukus 8y ago
  It's a failure of collaboration. For most single file libraries it would be better to have them bundled into a larger networking library that covers enough functionality to make adding and managing the dependency worthwhile. Eventually there will be a security vulnerability found and every app will be on some random version making it exploitable.
throwawaymath 8y ago
If you're implementing a new TLS library from scratch, why not reduce the available cryptographic agility and get rid of vulnerable versions? This implementation would be strictly more secure if it ripped out TLS 1.0 and 1.1 and didn't use RSA for anything. I don't mean to critique an honest effort here, if someone wants to make their own implementation that's great. But the world has enough cryptography that isn't secure by default, and I don't think backwards compatibility should be encouraged. How's My SSL [1] is a good resource (ignore that it still uses SSL nomenclature instead of TLS). To give an example, whenever I have to set up a new Nginx instance with HTTPS these days I remove TLS 1.0/1.1 support and disable half or so of the available cipher suites letsencrypt gives you out of the box. _____________________ 1. https://www.howsmyssl.com https://www.howsmyssl.com
- iforgotpassword 8y ago
  > I don't think backwards compatibility should be encouraged. Since you're talking about setting up a web server you can mostly get away with this, esp. since most people are on auto updating chrome, so it's not an issue. But try to configure your browser to be that restrictive and you'll get pretty annoyed very soon. I tried this about a year ago. Horrible experience.
  - lousken 8y ago
    I've set this up 3 months ago. So far only about dozen domains I visited were not reachable using TLSv1.2 or 1.3. I messaged to all admins and half of them fixed that already, other half either said it's not currently possible for that website because it's running on very old server or didn't reply at all.
    - sitkack 8y ago
      Is there an effort to build a whitelist for sites using old TLS versions?
      - lousken 8y ago
tptacek 8y ago
I didn't look very hard (I just jumped to the RSA decrypt function, then found its caller, then verified its caller was part of the actual handshake code) but this code looks like it has the Bleichenbacher padding oracle (it decrypts with RSA, in P1v15 padding, and generates a direct error if that fails; with chosen ciphertexts, those errors reveal and update bounds of the private key). Not at all sure (rather unsure) that this is practically exposed, but defenses against these kinds of attacks are why you generally want well-tested well-understood TLS implementations. A broader critique is that this one-file TLS state machine just delegates the gnarliest bits of TLS --- most importantly X.509 and ASN.1 --- to its library dependencies.
- throwaway12iii 8y ago
  You critique them for __NOT__ using well tested libraries, and then critique them __FOR__ using well tested libraries.
  - tptacek 8y ago
    No, you've misread.
  - will4274 8y ago
    The first critique is a specific vulnerability, not a general comment about libraries.
- tialaramex 8y ago
  Your assessment is correct, this code will send TLS alert packets when something goes wrong during RSA decryption otherwise it will press on. This means if you deploy this code adversaries can use your server as an Oracle to sign things with your private key even though they can't steal the key itself. Depending on how much bandwidth the adversary can get to you, it may be practical to attack clients doing PFS because the adversary can stall them and then use your oracle to have you sign the "Yes I'm really me" message they otherwise could not make. On the one hand, this problem doesn't make the code unsuitable for clients. On the other hand, this is not a subtle failure, this is specifically called out in the RFCs as something you need to do, so what else did they miss? By the way people, this sort of thing is why we're always telling you that wildcard certs and having a hundred unrelated SANs in a cert are dangerous. A box labelled "Bob's toy IRC server" running this code and sharing keys with your production web server makes "Bob's toy IRC server" into a working oracle for that production web server.
someguydave 8y ago
Oh wow I've always wanted Mark Karpeles' library in my stack of dependencies.

87 points by adulau 8y ago

I don't understand the fascination with "single file" libraries. Sure, you can take a well organized tree of a few dozen C files and turn it into a single ten-thousand-line monstrosity, but why on earth would you want to?

skrebbel 8y ago
I agree with you, but I guess you know that the answer is "because c still has no proper dependency manager so downloading a c file and adding it to the project/makefile/etc is often the easiest way forward"
- tedunangst 8y ago
  Except it still depends on libtomcrypt.
  - skrebbel 8y ago
    Hah! Yeah ok :-)
cjhanks 8y ago
If you are working on embedded software in an environment without robust dependency management, dropping in a file is the easiest way to add a feature. You also may want to minimize symbol leakage into a C program, a single file allows most functions and constants to become static.
throwaway12iii 8y ago
It's very common in the C/C++ world. The main reason is that you can easily use it in other projects. Until one of the C/C++ package managers gets good and wins, this is the nicest alternative. Note that people don't necessarily develop the libraries in one big file or don't have dependencies. Many newer libraries use a single C file as a distribution format. The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. If it pulls in hundreds of thousands of lines of code, that can be a problem. Also, small code is a requirement on some projects because of speed or memory limitations.
- black-tea 8y ago
  Yeah because it's really hard to include multiple files in another project...
- frutiger 8y ago
  > The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. The size of the code is independent of the number of files the code is in.
chrisseaton 8y ago
It's very useful in some parts of CS research to have be able to bypass complex build and linking systems and just be able to run an instrumented C compiler of some sorts. I think it's also people giving up on build systems and package managers.
simias 8y ago
Because C has no package system and it sucks, and having a single file (ideally with no dependencies, which isn't the case here) makes it super easy to integrate it anywhere. A good example of that IMO is cJSON[1], it's a small self-contained single file implementation of a JSON reader and parser. It's easy to use, the code is pretty clean and easy to follow and I never ran into any obvious limitation. I very much recommend it. There are also projects that are developed as multiple files but amalgamated into a single huge file before release. SQLite does that: https://sqlite.org/amalgamation.html https://sqlite.org/amalgamation.html > Over 100 separate source files are concatenated into a single large files of C-code named "sqlite3.c" and called "the amalgamation". The amalgamation contains everything an application needs to embed SQLite. The amalgamation file is more than 220,000 lines long and over 7.5 megabytes in size (as of 2018-11-24). > Combining all the code for SQLite into one big file makes SQLite easier to deploy — there is just one file to keep track of. And because all code is in a single translation unit, compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster. [1] https://github.com/DaveGamble/cJSON https://github.com/DaveGamble/cJSON
- peterwwillis 8y ago
  gcc -shared -o mycrypto.1.1.so file1.c file2.c file3.c file4.c #include "mycrypto.1.1.h" Doesn't that have the same effect of being easy to include? The amalgamation may be better for the compiler but I'm not sure why.
  - tialaramex 8y ago
    A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work. But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster. Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.
flukus 8y ago
It's a failure of collaboration. For most single file libraries it would be better to have them bundled into a larger networking library that covers enough functionality to make adding and managing the dependency worthwhile. Eventually there will be a security vulnerability found and every app will be on some random version making it exploitable.

throwawaymath 8y ago

If you're implementing a new TLS library from scratch, why not reduce the available cryptographic agility and get rid of vulnerable versions? This implementation would be strictly more secure if it ripped out TLS 1.0 and 1.1 and didn't use RSA for anything. I don't mean to critique an honest effort here, if someone wants to make their own implementation that's great. But the world has enough cryptography that isn't secure by default, and I don't think backwards compatibility should be encouraged. How's My SSL [1] is a good resource (ignore that it still uses SSL nomenclature instead of TLS). To give an example, whenever I have to set up a new Nginx instance with HTTPS these days I remove TLS 1.0/1.1 support and disable half or so of the available cipher suites letsencrypt gives you out of the box. _____________________ 1. https://www.howsmyssl.com https://www.howsmyssl.com

iforgotpassword 8y ago
> I don't think backwards compatibility should be encouraged. Since you're talking about setting up a web server you can mostly get away with this, esp. since most people are on auto updating chrome, so it's not an issue. But try to configure your browser to be that restrictive and you'll get pretty annoyed very soon. I tried this about a year ago. Horrible experience.
- lousken 8y ago
  I've set this up 3 months ago. So far only about dozen domains I visited were not reachable using TLSv1.2 or 1.3. I messaged to all admins and half of them fixed that already, other half either said it's not currently possible for that website because it's running on very old server or didn't reply at all.
  - sitkack 8y ago
    Is there an effort to build a whitelist for sites using old TLS versions?
    - lousken 8y ago

tptacek 8y ago

I didn't look very hard (I just jumped to the RSA decrypt function, then found its caller, then verified its caller was part of the actual handshake code) but this code looks like it has the Bleichenbacher padding oracle (it decrypts with RSA, in P1v15 padding, and generates a direct error if that fails; with chosen ciphertexts, those errors reveal and update bounds of the private key). Not at all sure (rather unsure) that this is practically exposed, but defenses against these kinds of attacks are why you generally want well-tested well-understood TLS implementations. A broader critique is that this one-file TLS state machine just delegates the gnarliest bits of TLS --- most importantly X.509 and ASN.1 --- to its library dependencies.

throwaway12iii 8y ago
You critique them for __NOT__ using well tested libraries, and then critique them __FOR__ using well tested libraries.
- tptacek 8y ago
  No, you've misread.
- will4274 8y ago
  The first critique is a specific vulnerability, not a general comment about libraries.
tialaramex 8y ago
Your assessment is correct, this code will send TLS alert packets when something goes wrong during RSA decryption otherwise it will press on. This means if you deploy this code adversaries can use your server as an Oracle to sign things with your private key even though they can't steal the key itself. Depending on how much bandwidth the adversary can get to you, it may be practical to attack clients doing PFS because the adversary can stall them and then use your oracle to have you sign the "Yes I'm really me" message they otherwise could not make. On the one hand, this problem doesn't make the code unsuitable for clients. On the other hand, this is not a subtle failure, this is specifically called out in the RFCs as something you need to do, so what else did they miss? By the way people, this sort of thing is why we're always telling you that wildcard certs and having a hundred unrelated SANs in a cert are dangerous. A box labelled "Bob's toy IRC server" running this code and sharing keys with your production web server makes "Bob's toy IRC server" into a working oracle for that production web server.

someguydave 8y ago

Oh wow I've always wanted Mark Karpeles' library in my stack of dependencies.