Wandering Thoughts archives

Current PC technology churn that makes me reluctant to think about a new PC

My current home computer will be five years old this fall. Five years is a long enough time in the PC world that any number of people would be looking to replace something that old. I'm not sure I am, though, and one of the reasons for that is that I at least perceive the PC world as being in the middle of a number of technology shifts, ones where I'd rather wait and buy a new machine after all the dust has settled. However, I may be wrong about this; I haven't exactly been paying close attention to the world of PC technology (partly because of my self-reinforcing impression that it's in churn now).

The first point of churn is in SSDs. It seems clear that SSDs are the future of a lot of storage, and it also seems clear that they're busy evolving and shaking out at present. We have ever larger SSDs becoming ever more affordable and on top of that there's coming changes in how you want to connect SSDs to your system. It seems quite likely that things will look rather different in the SSD world in a few years. I expect growing SSD popularity to affect both motherboards and cases, although that may be well under way by now.

The next point of churn, for me, is high DPI displays or more exactly the degree of graphics that I'm going to need to drive one, what sort of connectors it will need, and so on. I think the 'what connector' answer is some version of DisplayPort and the 'what resolution' is probably 3840 by 2160 (aka 4K UHD); I'd like something taller, but everyone seems to have converged on 16:9. On the other hand, this may be last year's answer and next year will bring higher resolution at affordable prices. Certainly the hardware vendors like improvements because improvements sell you things. In addition, the longer I wait the more likely it is that open source graphics drivers will support cards that can drive these displays (cf my long standing worry here).

Finally, there's the issue of RAM and ECC. One part of this is that I have a certain amount of hope that ECC will become more widely available in Intel chipsets and CPUs. Another part of it is that Rowhammer may cause changes in the memory landscape over the next few years. There are claims that the latest generation DDR4 RAM mitigates Rowhammer, but then there are also things like this Third I/O paper [pdf] that have reproduced Rowhammer with some DDR4 modules. Worrying very much about Rowhammer may be overthinking things, but there I go.

(I'd certainly like that any new machine wouldn't be susceptible to a known issue, but that may be asking too much.)

(There are other factors behind my somewhat irrational desire to not put together a new PC, but that's for another entry. Especially since I'm probably wrong about at least one of them.)

Some thoughts on ways of choosing what TLS ciphers to support

As you might expect, the TLS DROWN attack has me looking at our TLS configurations with an eye towards making them more secure. In light of DROWN I'm especially looking at our non-HTTPS services, the most prominent of these being IMAP. As part of this I've been thinking about various approaches to deciding what TLS ciphers to support or disallow.

(I'm going to use 'cipher' somewhat broadly here; I really mean what often gets called 'cipher suites'.)

There's a number of different principles for picking what cipher suites to support that one could follow here:

• Don't change anything and leave it to the software defaults. This seems like a bad option in today's Internet world unless you make sure to run the latest TLS software written by people who aggressively disable ciphers (at least by default). TLS risks and attacks just move too fast and TLS library defaults are often set conservatively (or simply not changed from historical practice, even when the threats change and some cipher suites become terrible ideas).

  The good news is that modern TLS libraries generally have disabled at least some terrible ideas, like SSLv2 and export grade ciphers. So some progress is being made here.

• Disable only known to be broken cipher suite options. Today I believe that this is purely RC4 or MD5 based cipher suites (plus terrible things like all export grade ciphers, SSLv2, etc). These are sufficiently dangerous that any client with nothing better is probably better off failing entirely.

  (Certainly we don't want user passwords traveling to us over TLS encryption that's this weak, never mind any other protocol vulnerabilities that they may expose.)

• Disable obscure, rarely used cipher suites as well as known broken ones. Today I believe that would add at least SEED and CAMELLIA based cipher suites. I've certainly seen various sites that advise doing this.

  (In some environments I believe that DES/3DES cipher suits would also be disabled here.)

• Set your cipher suites to the recommended best settings from eg Mozilla or other well regarded sources. These people have hopefully already worked out both what the good state of the art is as well as what tradeoffs you need to be broadly compatible with existing clients. You may need to supplement this with additional cipher suites if you have unusual clients.

  (Mozilla is great for HTTPS services but I'm not sure they've looked at, say, the TLS support levels in various IMAP clients. And current versions of web browsers are probably more up to date than clients for other TLS services.)

• Track your actual client TLS usage and then set your cipher suites to what your users actually need, plus the latest high security ciphers so that new clients or upgraded ones can get the best security possible. The drawback here is making sure you really know all of the cipher suites that your users are using; you may find that people keep turning up with uncommon clients that need new cipher suites added.

Any time you explicitly set the list of TLS cipher suites to use (as opposed to disabling some from the default list), you become responsible for updating this list as new versions of TLS libraries add support for new and hopefully better cipher suites. Sometimes you can be a bit generic in your explicit settings; sometimes sites have you set an explicit list of specific cipher suites. Just disabling things is probably more future proof, although the ice may be thin here.

I don't currently have any opinions on what approach is the best one. Really, I don't think there is a single 'best one'; it depends on your circumstances.