{direct link: brainpool.cryptostorm.org}


As we've moved torstorm through internal testing and external beta stage, we've been working to iteratively harden prospective attack surfaces for the entire service, as-deployed. This is a new tool and a new use-case, both to us and in general terms (a few folks have done tor2web services for several years, on and off, but large-scale production deployments are not in evidence, as far as we've yet noted), and security improvements for such a system are, by definition, iterative as well as baked-in at initial design stage.

One are we're currently tightening up is cipher suite selection for the torstorm <--> cryptostorm_exitnode leg of the topology. In that leg, the HTTPS wrapper is the sole boundary between plaintext and a passive-reconnaissance attacker. As such, ensuring good cipher suite selection is of nontrivial relevance to overall systems-level security for members making use of torstorm.

The initial beta build of the service relied on a pythonic backend to act as de-facto webserver. This placed some practical limits on the degrees of freedom we had in choosing our data-in-transit encryption framework for the service (yes, we can of course recode entire chunks of that backend, if necessary, to support just about any open cryptographic algorithms. However, as I've emphasised elsewhere, this kind of "roll your own" crypto implementation is hideously easy to screw up, in practice. So it's not something we jump into unless all other options are closed off.

Fortunately, we developed an alternative approach to the server-side resources that gets us back into widely-deployed web server terrain: nginx. That's a tool we know and use routinely for "creative" (read: weird) stuff like our tokenizer and other such oddities. So it's an ideal match for the torstorm deployment environment.

Once we're at that point, the question of cipher suite cascades comes into play. Our initial, somewhat default install produces a less than idea cipher cascade list:



Eek.

In addition to a big pile of weird cipher mismatches for a bunch of (mostly old) browser iterations, there's some cipher suites in that list that I'd not make use of for protection of a shopping list, let alone torstorm sessions!

At this point, I started manually pruning a meta-listing of all possible cipher selections supported by nginx (and our version of openssl: 1.0.1j); out goes SSL3, of course. And to hell with TLS 1.0 because it's just SSL3 in disguise wrt cipher vulns... RC4 is pretty much a broken mess at this point (and that's only on the civilian side - who knows what the NSA et al have up their sleeves), so we should really stick to GCM. Snip, snip, snip...

But, hold on.

Torstorm really isn't just a web browser for routine web-stuff. It's specifically for .onion Tor hidden services - one can safely infer that, in general, such bidirectional network sessions are going to want pretty strong protections against passive attackers, in particular. So instead of starting with the entire list of possible ciphers and pruning down, how about I build a "wishlist" of the ciphers I personally have come to conclude are worthy of production deployments? Yes, that's more like it: a kid in the proverbial candy story.

That list, it turns out, is pretty damned short. It's also a list that will - and this is why we've posted up this summary of the cipher selections, mostly - result in quite a few older browsers being unable to use torstorm. That's unfortunate, but we feel it's worth the cost. No session is, in many high-security scenarios, better than a session that is effectively leaky. That's not to say we're unconcerned with limiting access to the service; rather, just as with cryptostorm more broadly, we feel this is a realistic decision involving real-world risk mitigation and inescapable facts concerning many older cipher suites being used in HTTPS/TLS-based web deployments.

So what does that list look like. In a nutshell...



Yay! I'm a happy crypto-nerd.

But then we've got the matter of DH input parameters. Specifically...

All versions of nginx as of 1.4.4 rely on OpenSSL for input parameters to Diffie-Hellman (DH). Unfortunately, this means that Ephemeral Diffie-Hellman (DHE) will use OpenSSL's defaults, which include a 1024-bit key for the key-exchange.

Hence this:



...and the corresponding steps to make these materials available server-side, etc.

Now, our preferred mechanism for asymmetric key generation and corresponding so-called "perfect forward secrecy" in the channel is ECDHE. That means, by definition, there's an elliptic curve being used to generate handshake parameters for each asymmetric re-key. If we don't specify it, there's a default somewhere that gets used. A bit of poking shows this is what nginx is assuming for us, at this point:



This does not make me happy. At all.

Now things get complex and time-consuming, all of the sudden...

Here's what our openssl compile has to say for itself:

[email protected]# openssl ecparam -list_curves
secp112r1 : SECG/WTLS curve over a 112 bit prime field
secp112r2 : SECG curve over a 112 bit prime field
secp128r1 : SECG curve over a 128 bit prime field
secp128r2 : SECG curve over a 128 bit prime field
secp160k1 : SECG curve over a 160 bit prime field
secp160r1 : SECG curve over a 160 bit prime field
secp160r2 : SECG/WTLS curve over a 160 bit prime field
secp192k1 : SECG curve over a 192 bit prime field
secp224k1 : SECG curve over a 224 bit prime field
secp224r1 : NIST/SECG curve over a 224 bit prime field
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
prime192v2: X9.62 curve over a 192 bit prime field
prime192v3: X9.62 curve over a 192 bit prime field
prime239v1: X9.62 curve over a 239 bit prime field
prime239v2: X9.62 curve over a 239 bit prime field
prime239v3: X9.62 curve over a 239 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
sect113r1 : SECG curve over a 113 bit binary field
sect113r2 : SECG curve over a 113 bit binary field
sect131r1 : SECG/WTLS curve over a 131 bit binary field
sect131r2 : SECG curve over a 131 bit binary field
sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
sect163r1 : SECG curve over a 163 bit binary field
sect163r2 : NIST/SECG curve over a 163 bit binary field
sect193r1 : SECG curve over a 193 bit binary field
sect193r2 : SECG curve over a 193 bit binary field
sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect239k1 : SECG curve over a 239 bit binary field
sect283k1 : NIST/SECG curve over a 283 bit binary field
sect283r1 : NIST/SECG curve over a 283 bit binary field
sect409k1 : NIST/SECG curve over a 409 bit binary field
sect409r1 : NIST/SECG curve over a 409 bit binary field
sect571k1 : NIST/SECG curve over a 571 bit binary field
sect571r1 : NIST/SECG curve over a 571 bit binary field
c2pnb163v1: X9.62 curve over a 163 bit binary field
c2pnb163v2: X9.62 curve over a 163 bit binary field
c2pnb163v3: X9.62 curve over a 163 bit binary field
c2pnb176v1: X9.62 curve over a 176 bit binary field
c2tnb191v1: X9.62 curve over a 191 bit binary field
c2tnb191v2: X9.62 curve over a 191 bit binary field
c2tnb191v3: X9.62 curve over a 191 bit binary field
c2pnb208w1: X9.62 curve over a 208 bit binary field
c2tnb239v1: X9.62 curve over a 239 bit binary field
c2tnb239v2: X9.62 curve over a 239 bit binary field
c2tnb239v3: X9.62 curve over a 239 bit binary field
c2pnb272w1: X9.62 curve over a 272 bit binary field
c2pnb304w1: X9.62 curve over a 304 bit binary field
c2tnb359v1: X9.62 curve over a 359 bit binary field
c2pnb368w1: X9.62 curve over a 368 bit binary field
c2tnb431r1: X9.62 curve over a 431 bit binary field
wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
Oakley-EC2N-3:
IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
Not suitable for ECDSA.
Questionable extension field!
Oakley-EC2N-4:
IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
Not suitable for ECDSA.
Questionable extension field!

Meh.

Here's why the 'meh' happens:



Basically, there's all sorts of serious mines hidden in those curve options. For example, this little gem:



Last year Schneier, after having firsthand access to the Snowden documents (some of them, for a limited period of time), made this somewhat enigmatic observation - which was often misconstrued as suggesting that ECC was "pwned by the NSA" but is in fact a huge red flag for NIST-validated curves and their attendant generation parameters:

Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.

Here's ./'s summary of the whole thing (which is more or less accurate):

"In the wake of Bruce Schneier's statements that he no longer trusts the constants selected for elliptic curve cryptography, people have started trying to reproduce the process that led to those constants being selected ... and found it cannot be done. As background, the most basic standard elliptic curves used for digital signatures and other cryptography are called the SEC random curves (SEC is 'Standards for Efficient Cryptography'), a good example being secp256r1. The random numbers in these curve parameters were supposed to be selected via a "verifiably random" process (output of SHA1 on some seed), which is a reasonable way to obtain a nothing up my sleeve number if the input to the hash function is trustworthy, like a small counter or the digits of PI. Unfortunately it turns out the actual inputs used were opaque 256 bit numbers, chosen ad-hoc with no justifications provided. Worse, the curve parameters for SEC were generated by head of elliptic curve research at the NSA — opening the possibility that they were found via a brute force search for a publicly unknown class of weak curves. Although no attack against the selected values are currently known, it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies. Now that the world received strong confirmation that the much more obscure and less widely used standard Dual_EC_DRBG was in fact an NSA undercover operation, NIST re-opened the confirmed-bad standards for public comment. Unless NIST/the NSA can explain why the random curve seed values are trustworthy, it might be time to re-evaluate all NIST based elliptic curve crypto in general."

(it's worth noting that, since these 2013 revelations, nothing's been disclosed or even really mooted seriously that questions these conclusions; true, the backdooring has not been formally proved via mathematical analysis - which is astonishingly difficult to do, in the best of circumstances, in such matters - but the smoking guns still smoke and the surrounding fact patter of other NSA malfeasance = Dual_EC_DRBG, anyone - adds up to a totality of circumstances impossible to ignore)

Sigh. There's some least-bad options... sorta. None gives me much confidence.

Then OpenSSL's current version 1.0.1j doesn't support alot of the ECC curves that we do like, in particular Curve25519. That's possible, of course - there's some nicely-done libraries out there, and likely that's where we go with this in the medium term (as in our main network cipher framework) - but making on-the-fly edits to OpenSSL's C is not something we'd do iteratively. Hence, what's out there that's (more or less) known-stable, and has decent curves?

Brainpool.

Yes, I know. There's considerable controversy here (perhaps a stronger word is really most appropriate). DJB & Co. pretty well lay out the issues...



And, yes, we much prefer 25519. But Brainpool - or some curves in Brainpool - are a hell of alot better than NIST garbage. But OpenSSL doesn't have production Brainpool support. Yet. Well... almost. Their nearly-production version 1.0.2 does:

patches extending OpenSSL's built-in set of EC curves by the Brainpool
curves (see RFC 5639) have been around since 2010 - see for instance
http://openssl.6102.n7.nabble.com/opens ... 41171.html
http://rt.openssl.org/Ticket/Display.ht ... pass=guest

Pleased to see that finally, three years later, they have been included
in the upcoming version 1.0.2. - I have been able to verify this from
http://mirrors.ibiblio.org/openssl/snap ... 125.tar.gz

In particular since the usual NIST curves got under pressure recently:
http://it.slashdot.org/firehose.pl?op=v ... 11/1224252
it is important to have some less debatable alternatives available for
general use ASAP. When can we expect version 1.0.2 to be released?

So, off to compile OpenSSL 1.0.2, and then re-compile nginx, and then choose a curve from Brainpool. The obligatory compile adventures ensue, until at last here's the new curves that OpenSSL spits out on our machine, as options:

brainpoolP160r1: RFC 5639 curve over a 160 bit prime field
brainpoolP160t1: RFC 5639 curve over a 160 bit prime field
brainpoolP192r1: RFC 5639 curve over a 192 bit prime field
brainpoolP192t1: RFC 5639 curve over a 192 bit prime field
brainpoolP224r1: RFC 5639 curve over a 224 bit prime field
brainpoolP224t1: RFC 5639 curve over a 224 bit prime field
brainpoolP256r1: RFC 5639 curve over a 256 bit prime field
brainpoolP256t1: RFC 5639 curve over a 256 bit prime field
brainpoolP320r1: RFC 5639 curve over a 320 bit prime field
brainpoolP320t1: RFC 5639 curve over a 320 bit prime field
brainpoolP384r1: RFC 5639 curve over a 384 bit prime field
brainpoolP384t1: RFC 5639 curve over a 384 bit prime field
brainpoolP512r1: RFC 5639 curve over a 512 bit prime field
brainpoolP512t1: RFC 5639 curve over a 512 bit prime field

Still not making my nipples hard, but at least better (I think, based on what I've seen in the literature). From the list, I choose brainpoolP512r1, we plug it into nginx as a parameter, and let's see what happens...



Oops.

The usual to'ing & systracing goes on until we hunt down the fiddly bits that need to be fiddled. Fiddling ensues, and nginx seems to be settled into a life in partnership with OpenSSL 1.0.2.

Let's take a test drive over to @IvanRistic's SSL Labs testing page, and see what happens:



Derp. Perhaps we're just throwing enough Brainpool-y weirdness at it that it's not sure what's up. How about CA Security Council's tool?



Well ok then. Let's look at some packets (via tcpdump) in transit and see if we've somehow (implausibly) broken HTTPS and caused it to barf up plaintext, mysteriously:



Doesn't look that way, at face value anyhow.

There you. It appears we've got curve brainpoolP512r1 in production and fairly secure against known backdoors. Needs quite a bit more testing before we declare it full production, obviously - and our beta testing warnings in the project launch announcement very much stay in effect. Still and all, not a bad spot of work - lots of detours and roundabouts, but in the end we might just have done something useful with our time.

Next up? Proper Curve25519 deployment via NaCl libraries... unless someone's got an existing way to bump it into OpenSSL, that doesn't suck. Which should be entertaining, either way.

- - - - - -

It's far easier to simply choose default settings, especially when it comes to crypto. Once you go out of default-land, things can get complex. Plus, which non-defaults are best? And when you start messing with new compiles to wrap in well-proven cipher capabilities that - for whatever obscure reasons - aren't yet part of a given package, it can get a bit interesting. This time could have been spent writing clever marketing campaigns, or sending out press releases, or bribing "VPN review" websites into saying good things. That's what everyone else does, to be blunt about it.

But, look: why fucking bother with crypto in the first place, if you deploy broken shit? Honestly. Why? If you know it's backdoored, what are you gaining by pushing it out into production? The NIST ECC curves are backdoored - put a gun to my head and make me take sides in a final bet, and that's where I put my chit. Who has those "magic numbers" that allow for a trivial reconstruction of point-pairs? Dunno. And I am not even interested in spending the fucking time to figure out who may or may not, because... if there's stuff that we are pretty sure isn't backdoored (or at least we don't know of them yet, and so on), how about we use that instead. Seems reasonable.

It's not like non-backdoored curves "cost more" or something - it's all open code, open algorithms. And the alleged "performance hit" of this stuff is, in our production context, a total fantastical creation. It doesn't exist.

Yes, it takes more work to do it right (or as right as one can, with what one knows and has available). We think that's an interesting process and, quite often, a spot of fun as well. It can also result in horrific bughunt deathmarches, days without sleep, missed launch dates, derision if it breaks post-production, and a general sense that one is always skirting that fractal boundary between real success and roiling chaos.

But the real reason this isn't done more often, I think, is this: it's not really visible. Sure, you can pull pcaps and (in theory) confirm we're using brainpoolP512r1- well, someone with a hell of alot of capability in such things can (that's no wireshark capability we'e seen floating around thus far). In practice, nobody does this. Nobody. So it's all invisible, behind-the-scenes stuff. Likely to never even be noticed by members who are using it.

When we do stuff right, nothing happens. When secure systems don't break, no information leaks. Nothing bad happens to members. Nothing happens. We chew on this stuff and do our best to make it good, with the goal of nothing happening. Which, of course, is not exciting news for the most part: someone uses cryptostorm, an attack they don't know is taking place fails because we did something right, months or years ago, in our architecture or deployed framework. And... nothing happens.

Tokens sold due to such work? Zero, basically. Bills paid as a consequence of doing it right? None, for the most part. That's just reality. We'd do much, much better financially if we paid off a news website to hype our alien-proof technology than we are by actually producing a service that isn't riddled with obvious security fail. It's a bit of a bitter pill, sometimes, to watch it all play out.

Ha, fuck it anyhow! Doing it right feels good. It's hard, and frustrating, and often under-appreciated. Who really cares? That's not the point. The point is that doing it right feels good - because it's done right. And lots of good things flow from that simple stance. Do it right, as best you can. Then keep doing it better. How about that?

How about it, indeed.

Cheers,

~ pj

@PJMany thanks for posting this, it's been very instructive and useful. Question: what is the cypher test suite which produced the image at the beginning of your post?

Sky five!


Nice work fella... I understood most of the words
Thanks for putting in the work, sure it pays dividends

@PJMany thanks for posting this, it's been very instructive and useful. Question: what is the cypher test suite which produced the image at the beginning of your post?

Oh, that's just the Qualys test site - there's enough length to a page that a full screenshot if it ends up being a bit unwieldy.

And, look, it's giving actual readings for torstorm.org now! And it's weird. Ha - always an adventure. Let's see what this is about, now...

Cheers,

~ pj

So here's what our host machine says, right now are the only nginx cipher suites it will support, period:

[[email protected] conf.d]# grep ssl_ciphers d*
ssl_ciphers "AES256+EECDH:AES256+EDH";
ssl_ciphers "AES256+EECDH:AES256+EDH";

Here's what ssllabs.com thinks is being supported:



The "mismatch" items are expected - that tells us those browser packages simply can't support the required server-side; as discussed above, that's an intentional choice.

And then it says we're using only DHE for asymmetric key exchange. DHE is fine, don't get me wrong - not the best performance relative to ECDHE, which is why we've gone ECC on this one. So having DHE show up, instead of ECDHE... that's like your house suddenly being blue when it was grey yesterday. Sure, both might look ok... but how the fuck did the house change colours overnight?.



Likely it's to do with the custom brainpool curve stuck in, or us using openssl 1.0.2 before it's officially released. In any case, poking at it now...

Always and adventure.

Cheers,

~ pj

Also wanted to point out how important the smileys are in cipher cascades, as we all know:

We figured it out. I think.

Nginx has this weird nomenclature for cipher suites, backwards almost:

DHE = EDH
ECDHE = EECDH

Blah. So we've got either DHE or ECDHE as optional suites in nginx. And somehow, out of that, ssllabs is getting a report that only DHE is available. Which is not what we want. So we're changing cipher parameters to:



In no small part because that's top-of-list preference in Chrome 39, and thus AGL's preference, and... it makes sense (no surprise). There's heavier symmetric firepower available, but in the context of GCM-v-CBC... yeah, I totally see his point. So that's our suite.

...and we'll see what happens

Cheers,

~ pj

Ok, edits to nginx done and here are the new test results:



Downside is, under current parameters, if you're using even current IE versions, I think torstorm is not going to let you in. That may not be a decision that we can support in full production; we'll see...

Cheers,

~ pj

@PJ

...if you're using even current IE versions, I think torstorm is not going to let you in. That may not be a decision that we can support in full production; we'll see...

I'll put up an argument for keeping things as they are: Cryptostorm's primary mission is security, above everything else. This stance is the same reason you don't support port forwarding for torrents - it would make torrent swarms more efficient, but that's not the mission of Cryptostorm. This stance is the same reason you don't currently support on-net hidden services - it's a security risk and doing it properly is tricky.

There's nothing stopping members from using another (and from this security perspective, better) browser. Security first, everything else afterwards. Very simple.

parityboy wrote:I'll put up an argument for keeping things as they are: Cryptostorm's primary mission is security, above everything else. This stance is the same reason you don't support port forwarding for torrents - it would make torrent swarms more efficient, but that's not the mission of Cryptostorm. This stance is the same reason you don't currently support on-net hidden services - it's a security risk and doing it properly is tricky.

There's nothing stopping members from using another (and from this security perspective, better) browser. Security first, everything else afterwards. Very simple.

Fair enough, and that's certainly the balancing side of things.

The other side is that I really need to sit down and determine whether, based on all the known attacks and all the possible attacks and all the paranoid fears of potential future attacks, there's enough of a risk in using the stepped-down cipher suites. In this beta deploy, I just took the easy approach of "yep, that one thar is a suite I'd seriously fucking bet my life on in a crunch - and not lose any sleep in doing so" - and we put that into production. That's a luxury.

But can I defend that, in terms of next-step-down suites? That's the real question. Just turning everything up to "11" feels like "good security," but if you make it impossible to use stuff, then you sort of suck as a security technologist. The most secure computer is the one you never turn on, or never buy, or never manufacture, after all

But if I really look at that suite, and think "fuck's sake, I'd not use that shit if the stakes were high"... then, nope, we won't use it.

Crypto deployment ruminations, with perhaps a bit more profanity than is usually the case - cold weather does that!

Cheers,

~ pj

It's one thing to consider security > convenience, and another to totally bottleneck the fuck out of the machine the user is using to connect to the darknet. You've got a big decision to make, I just ask you don't shine favour on your *nix penpals... and keep in mind, people still out there use IE or prefer Windows.

After all, Windows did allow me to use VPN1(CS), then fire up a VM to connect to VPN2, then connect to Tor... effectively UDP / UDP / TCP with no leaks according to Wireshark. If Windows can do that and still provide me with a downstream at the end (Tor side), middle (post VPN2 connection) and beginning (post-CS connection), then maybe it isn't as shit as people think.

marzametal wrote:It's one thing to consider security > convenience, and another to totally bottleneck the fuck out of the machine the user is using to connect to the darknet. You've got a big decision to make, I just ask you don't shine favour on your *nix penpals... and keep in mind, people still out there use IE or prefer Windows.

After all, Windows did allow me to use VPN1(CS), then fire up a VM to connect to VPN2, then connect to Tor... effectively UDP / UDP / TCP with no leaks according to Wireshark. If Windows can do that and still provide me with a downstream at the end (Tor side), middle (post VPN2 connection) and beginning (post-CS connection), then maybe it isn't as shit as people think.

This is solid input, and appreciated. I'm vastly more in alignment with you on all points, than I am in any disagreement.

Despite appearances, we aren't *nix snobs here - not even close. Several devs work daily on Windows machines, and more than a few prefer them for most work. A few of us are more Linux-y, basically to ensure we've got a competent balance with the non-Windows side of things. The truth is, we tend to use our Linux friends as crash test dummies for new (pre-beta) stuff, as they are often willing to help corral loose concepts into functional tools - something many Windows users (quite reasonably!) expect will be done before they see it on their machines.

That's why there may seem a Linux tilt - so much test-dummy use here, as we work out the kinks of new stuff. In point of fact, the ratio of actual client-side development investment, in terms of staff hours, invested in Windows as compared to Linux is at least 20 to 1 in favour of Windows! The widget reflects a great deal of careful, patient, iterative dev work for more than a year running; in contrast, Linux connects are pretty much: "here's the config file, good luck!"

Which is to say, I have zero desire to kneecap Windows folks - or anyone else - in cipher selections. I only realised the issue when I glanced at the test results from my selection and realised it seemed to cockblock IE. So I'm doing an immediate review of that - and also hoping folks will actually confirm (or deny) that IE can't make torstorm connections under the current cipher regime.

The folks who do get kneecapped in this are anything in Android that's not really current. That's unfortunate, but I doubt we'll be able to stretch and meet them somewhere in the middle... cipher support just isn't great in those builds.

Tbh, I don't even know why IE isn't showing showing support for the cascade chosen - it's not idiosyncratic in any substantive sense, really. So perhaps there's a simple thing here - I simply haven't looked back to review it yet, as I wanted to give a bit of breathing room to clear my head and ensure I'm seeing things without blinders on.

Our poor support really does lie with our Apple/OSX work - we have nobody on our team in that world, and we're constantly struggling to do a decent job of providing assistance and useful tools. Actually a new addition to our dev team is making great improvements there - about damned time, really! That's an embarrassing area for us, it really is; Windows, in contrast, gets by far the lion's share of our client-side work and always has. Which is fair.

Personally, the only thing I might quibble with in Windows - and this is not a flaw - is that it's fairly easy to break it if one is doing strange modifications to obscure components of the kernel and core components of the OS. As we do quite a bit of that in our dev work, it's easy to break Windows boxes - which can be time consuming. Linux is just as easy to break, but usually easy to un-break as well. So for some of the weirder front-line testing work, I know I gravitate to Linux because it's easier to iterate through colossal fails.

(yes I know, use VMs - sounds great, but in network-heavy context and involving weird adapter-specific fiddling, going virtualised adds entire new layers of complexity and moving variables and, frankly, it ends up being deeply confusing to figure out what the hell just happened more often than I can comfortably handle; for actual coding of proper applications, sure I can see the benefits clearly... but we're often as not playing strange chords on parameters in multiple intertwined layers of the PSI model; adding in virtual exotic particles doesn't really make that task any easier, at all)

Cheers,

~ pj

Cheers PJ...

@PJ

Count one *nix snob, right here. Seriously though, I see both sides of the argument and having look at the SSL Labs report, I can see a lot of people being knocked out. I don't know close your ears are to the ground in terms of the devices used by the activists/network members you support, but I know there are a lot of OS X 10.6/10.7/10.8 users out there who like and use Safari, and they will be shut out.

Just out of curiosity, I searched for browser market share and found this. No claims as to accuracy, but I'll take a guess and say that the browser share among network members (who are not necessarily Tor Hidden Service users) will be somewhat reflective of the overall picture.

On a related note, I've recently gotten hold of an iMac (late 2009 model) and an iPad 2, so I'll be happy to provide "guinea pig time" for the 'storm.

@PJ The shit you ponder, is one of the key reasons I choose to risk my shit with CS.
Always up for OSX/iOS testing if needed.

@b3lt3r5

Your reasoning is exactly the same as mine. PJ's musings have been very useful for me for a project I'm developing.


@PJ

You mentioned in the orginal thread about web<->Tor traffic having to go across an unencrypted plane (the SOCKS interface on the Tor relay). If that plane could somehow be secured, and then the box was rooted (an assumption any sensible person must make) would that localised packet encryption really make any difference?

I'm asking this in the context of a service I wish to build, having been inspired by your Web<->Tor gateway.

parityboy wrote:You mentioned in the orginal thread about web<->Tor traffic having to go across an unencrypted plane (the SOCKS interface on the Tor relay). If that plane could somehow be secured, and then the box was rooted (an assumption any sensible person must make) would that localised packet encryption really make any difference?

I'm asking this in the context of a service I wish to build, having been inspired by your Web<->Tor gateway.

In a word, no.

Anything one might do to "lock down" the transit of the data traffic across the proxy layer could be un-done by someone with root. I'm aware of no tools, nor even a concept of a tool, that could address that sort of issue (apart from end-to-end, continuous-segment data encryption).

Cheers,

~ pj

@PJ

Many thanks for that; I guessed as much but confirmation is always nice. I believe separating the boxes might be better - but against certain adversaries even that might be futile, depending on their reach. Would it be then fair to say that the best a system admin can do is install intrusion alarms and wait for them to trigger?

@parityboy Must be an interesting project then. Looking forward to hearing how it goes.

@b3lt3r5

Well, no harm in revealing it: it's a Web<->I2P gateway, for network members. The I2P router has interfaces for HTTP and SOCKS. It can also either proxy or terminate HTTPS, hence the questions around local encryption - getting mod_proxy to make a local SSL connection to the I2P router. As PJ correctly points out, if the box is rooted (as in root access, as opposed to merely mounting the filesystem), while data travelling across the lo interface would still be encrypted, there is nothing stopping an attacker reading the unencrypted data either side of the SSL sockets.

*sigh*

I could build it as a two-box solution with a box in different data centres, just to make life more difficult for an attacker, but to be honest for something like this it may not make much difference if just one of the boxes is compromised - the data will be unencrypted at some point in its transit.


@PJ

Would it be possible to mitigate some of this threat (separately from the usual hardening steps) with a traffic-generating robot? The idea would be to set up a few (very) cheap VPSes, each running a robot which generates a certain level of web traffic, and identifies itself as a popular browser. The challenge here is to know which I2P sites would be of most interest to people (on both sides) and then generate traffic for them. Even so, do you think this would be worth doing? Or perhaps modify mod_proxy to create random delays when sending or receiving data?

Not really happy to do this, but I'm adding the following cipher suite to the torstorm nginx backend:



It unpacks to TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, or hexcode [0x9f]. That is supported by IE 11.whatever, and more broadly by most current IE builds.

I can't say this is legitimately a security issue, as I have confidence in DHE and the only real upside to ECDHE in comparison (even with a brainpool curve or, ideally, c25519 or c3617 or other top-class curves) is performance. Although I have a sense that ECC stands up to future quantum-based attacks better than DHE, I have exactly zero empirical basis for this hunch and in fact most smart folks consider ECC and discrete logs to be essentially commutative, especially wrt quantum attacks.

The alternative to this is to give up GCM for CBC and... no. I'm not doing it, not for torstorm. So it's DHE, which may be a performance hit on some older machines. We'll see what feedback is, in the wild.

Apologies to everyone for the delays in greenlighting this cipher suite addition. I've chewed on this far longer than I can really justify, and in the end the choice in favour of DHE over a loss of GCM really seems utterly self-evident. I suppose it was just necessary for me to slowly inch my way to this obvious outcome.

Here's the IE 11/Win 8.1 supported cascades, as reported by Ivan's test suite:



Bizarrely, however, [0x9f] isn't supported by IE11 running on Win7. Why? ...why?!?

Indeed, Microsoft's cipher suite deployment decisions seem, in a nutshell, inexplicably designed to have at least one flaw, no matter which option one chooses.

Sigh. Anyhow, it's likely we'll have to open up a few more suites as we move forward.



Obviously, IE11 folks won't be running brainpool curves, or ECC at all. However, we're still putting cipher suites into production that are both PFS-proofed and not vulnerable to already-documented attacks. That's something, even if it's not perfect in a formal sense.

Cheers,

~ pj

edited to add: I went ahead and put these three into production, for now, as it seemed inevitable they'd all end up being needed to cover Firefox, OSX/Safari, & modern-ish Android versions:



I'm still torn on the CBC inclusion, but without it many Android folks are barred from torstorm and, on balance, I don't think these attacks are deep enough in practical terms to pose an existential threat. Or I am telling myself that as of this afternoon; we'll see if I can continue to defend that position after I've stepped away from it for a bit. Meh.

I'm not even remotely close to be an expert like you are but I also grew desperate on this topic when I tried to secure a server. There is just no cipher suite available at the moment that is both 100% acceptable from a security stance but also compatible with all popular browsers and OS. If you want to reach an acceptable solution you are simply forced to sacrifice either some compatibility or add some less secure ciphers. On private servers you can easily opt for security but when you want to serve a public audience you probably have no choice but to opt for compatibility. It's no shortcoming of the people running a server but the fault of those who decide what ciphers are implemented in their software. But that's makes it all the more frustrating because you are forced to make decisions you don't want to make.

@PJ

One thing I noticed from your posts is your preference for GCM. I know zero regarding this mode of operation (going to look at it now) but I notice that OpenVPN (at least with regard to CryptoStorm) doesn't appear to support it - CS connections use AES-256-CBC. Is this due to a total lack of support on OpenVPN's part, or other reasons?

Here's what we've got, with the new suites in production, per SSL Labs:



I'm not sure why we're still showing fails for IE11/Win7 (& similar Windows browsers) but I'm hoping to replicate that with actual browser sessions before we go on a bughunt.

Cheers,

~ pj

Did a quick client check on SSL Labs with my Windows 7 VM and IE11.
I won't do any testing with this VM though. I don't trust this OS even half as far as I can throw Satya Nadella. Sry...

@PJ

Just did a quick test to the DuckDuckGo .onion website with Internet Explorer version 11.0.9600.17501 on Windows 7. Works as expected, as does the Onion URL Repository.

Heya PB - we're getting reports of some cipher mismatches on some browsers. I'm not yet opening the task to formally review these cipher primitives... but I suspect it'll need to be done sooner rather than later. Because c25519, maybe? One can always dream, eh?

Any help in pinning down such reports is appreciated; we've pruned supported ciphers so tight that any fudge and sessions will proactively abort (as was intended, on our part). But it does lessen the usefulness of torstorm when it won't actually load in modern browsers!

Cheers.

DesuStrike wrote:Did a quick client check on SSL Labs with my Windows 7 VM and IE11.
I won't do any testing with this VM though. I don't trust this OS even half as far as I can throw Satya Nadella. Sry...

Selection_118.png

Heh, nice to hear your voice in here, my old friend!

Cheers

@PJ

I've just done a quick test on Safari 9.0.3 (10601.4.4) and on Firefox 45.0, both running on OS X 10.10.5.The test is simple - go to https://3g2upl4pq6kufc4m.torstorm.org (DDG hidden site).

The OS X machine was taken off-net to conduct a "cleaner" test. I get this as the result from Safari:


Firefox behaves (almost) as expected - the DuckDuckGo logo does not appear above the search input box.

UPDATE
Did a quick SSL Labs report, so see attached (image is split).