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

> 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.

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.

Sorry, I probably should have been more explicit. I was also referring to the part where they suggested disabling weak ciphers, like explicitly stated in GP, RSA. That's what caused problems for me.

That depends on what do you consider as a weak cipher, I do have security.ssl3.rsa_des_ede3_sha set to false in Firefox as well. If you mean all ciphers that don't have forward secrecy then I guess it may broke a lot more.

edit: i also have security.ssl3.rsa_aes_256_sha disabled, so my only non forward secrecy cipher fallback is TLS_RSA_WITH_AES_128_CBC_SHA

I would suggest to avoid disabling ciphers in your browser as it can damage your privacy.

Is there an effort to build a whitelist for sites using old TLS versions?

I don't have any plans for creating such whitelist, if webmasters and sysadmins don't respond to my emails they will be forced by browsers anyway - in one year the most commonly used browsers will disable TLS 1.0 and 1.1 with an update [0]. For now it serves as a good warning that such webserver isn't updated and might be hacked sooner or later. With pretty much every distribution released in last ten years you can patch it so that apache/nginx or whatever will use TLS 1.2 and if you're using something even older it probably shouldn't be on the internet anyway.

[0] https://www.zdnet.com/article/chrome-edge-ie-firefox-and-saf...

I have Firefox configured to reject 1.0 and 1.1. Pretty much the only thing that refused to connect was a university's learning management system. The vast majority of websites support TLS 1.2.

Yeah, but 1.2 still supports a lot of "shitty" ciphers. Try disabling them too...

TLS 1.2 is from late 2008, so it's pretty reasonable to start support from there unless you have a good reason.

It's embarassaing that Android didn't enable support for TLS 1.2 everywhere until 5.0 (lollipop), but that was released late 2014, and most of 4 _can_ use 1.2 if you use the right options when making your sockets. And most people stopped supporting anything before Android 4.

Indeed, there's a very long tail of sites out there which still have useful and hard-to-find niche information but haven't upgraded to newer software, and I don't blame them for it --- since they're usually self-hosted, if you complain they're more likely to just shut it off, which would be even worse.

Every once in a while I envision a desolate future where survival is dependant on scavengers being able to break into discarded computer systems. At which point, weak crypto would actually save the world.

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.

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.

You critique them for __NOT__ using well tested libraries, and then critique them __FOR__ using well tested libraries.

The first critique is a specific vulnerability, not a general comment about libraries.

No, you've misread.

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?

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

> 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

Tossing everything into a single file is not required.

You can use includes to have "a single file to add to the project", and still split your code in smaller, readable files.

See https://github.com/jedisct1/libhydrogen for example. It's a single-file crypto library from an application perspective, but everything was not stored into a single, hard-to-navigate file.

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.

Now do it on Mac, and windows, and dynamic and static, and install the libraries in the right place. It gets maddening.

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.

The compiler invocation above only creates a single object file.

No, but I can see why you thought so.

The invocation above creates one object file for each C source file, as temporary files, (in a Unix system you can watch it do this with a suitably powerful syscall tracer, presumably something similar is possible on non-Unix systems but I don't know exactly how)

Then it links them and produces the output you've mistaken for an "object file", then it deletes the temporary files.

Ah, probably the easiest way to deal with some translation unit edge cases. :(

> compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster.

does this hold even when non-amalgated code uses `-flto` or equivalent flag?

I don't know what's the state of the art for link time optimization these days but I would assume that it's still somewhat more limited than compile-time optimization. You can usually be a lot more aggressive when you have the full context of the code being optimized.

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"

Except it still depends on libtomcrypt.

Hah! Yeah ok :-)

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.

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.

> 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.

Yeah because it's really hard to include multiple files in another project...

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.

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.

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