SNI is now supported by all the major players (IE was the last hold out) but... I'm pretty sure the current free cert providers don't support it.
SNI requres support from (a) the browser, and is near-universally supported by all browsers these days and (b) the web server, with many hosts supporting it already. If not, they should.
The certificate authority is not involved with SNI at all.
If fighting is sure to result in victory, then you must fight!
Sun Tzu said that, and I'd say he knows a little bit more about fighting than you do, pal, because he invented it, and then he perfected it so that no living man could best him in the ring of honor.
Then, he used his fight money to buy two of every animal on earth, and then he herded them onto a boat.
And then he beat the crap out of every single one.
And from that day forward any time a bunch of animals are together in one place it's called a 'zoo'!
OMG what are you on and do you have enough to share?
It's from Team Fortress 2's "Meet the Soldier" trailer.
From the summary: "While this makes VeraCrypt slightly slower at opening encrypted partitions..."
On my 2.4GHz, 4-core, 8-thread i7-3630QM mounting an encrypted partition using VeraCrypt takes ~18 seconds. It takes the VeraCrypt bootloader more than 40 seconds to verify my password and proceed with booting.
Although one need only enter the boot password once at boot time, it's still a bit of a pain. A 1-5 second processing delay is reasonable, but more than 40 seconds? Either way, a few thousand iterations combined with a strong password makes brute-force guessing impractical so why bother with obscenely high iteration counts?
I'd much rather that VeraCrypt (or other similar software) allow one to set the number of iterations so one could set the desired delay time based on their own hardware and threat model, and have the iteration count written to the disk so the software knows how many iterations to use. For me, I use such software to protect against theft by ordinary criminals: they're not going to bother decrypting the drive, so a second or two of iterating is fine. Those defending against more well-funded adversaries would be better served with more iterations.
If there's a single systemic problem with HTTPS, it's that we're still largely relying on Certificate Authorities which charge a lot of money. The expense and complexity discourages people from using SSL more ubiquitously.
Cost is an issue if you're buying VeriSign certs for hundreds of dollars, but why waste your money? (Answer: nobody got fired for buying VeriSign, and big companies think customers care about the "trust seals"). Other CAs offer OV or EV certs for less than $200/year.
DV certs are incredibly cheap. StartSSL offers DV certs for non-commercial purposes free-of-charge. For paid certs, they only charge for what costs them money: ndividuals can get their ID verified for $60/year and issue unlimited Class 2 certs. Organizations pay $120 (one individual verification, plus the organization verification) and can issue unlimited certs. Gandi offers DV certs (they're a Comodo reseller) for $16/year. NameCheap (a reseller of several CAs) has even lower prices: Comodo certs are $9/year, while RapidSSL certs are $10.95.
I hardly consider $9/year to be a showstopper for even the most cash-strapped business or small organization.
That said, you do have a point in regards to complexity: generating certs using command-line tools is not something the typical user can be expected to do, particularly with subtleties like adding the right flag for SHA2 signatures, configuring their server with good ciphersuites, etc. Heck, I routinely see professionally-managed websites with SSL cert chains missing the intermediate cert. Security is complex and can only be simplified so much, but it's still an issue.
What is the alternative? Phone calls?
Several email services (e.g. Gmail, Yahoo, etc.) do just that: they can send voice calls or SMS messages to a phone number you've registered with them prior to the loss of your account.
Due to the importance of email addresses when it comes to authentication (e.g. password resets for non-email services are nearly always sent to one's email address) it makes sense to have email services be secure from compromise (e.g. 2FA) and recoverable in a secure manner (e.g. phone-based validation).
Domain names are also a "high-stakes" thing and it makes sense to have a high degree of security when allowing password resets at registrars: I wouldn't mind my domain registrar sending me a letter by post to my address on file with them if I were to ever request a password reset from them.
I'm curious, how's the performance of YouTube and Netflix over there. Do you notice a bottleneck most likely traced at the trans-Atlantic fiber pairings, or is all content cached on local servers too?
Google has many datacenters, including three in Europe. Alas, due to Google not providing reverse DNS on a lot of their router hops I'm not sure quite where the traces end up, but they're only ~30ms away from Bern, so the connection is definitely routed to their European facilities.
As for Netflix, their European service seems to be run from the Amazon AWS facility in Ireland, so there's no transatlantic links to cross. I imagine they also offer their CDN equipment to European ISPs, but they don't offer Netflix in Switzerland yet, so I don't know if that's the case here. I subscribe to the US Netflix and use Unlocator to trick their location-detection system into thinking I'm in the US, so the videos I watch do cross the Atlantic. There's maybe 10 seconds of lower-resolution video when streams from US Netflix first start, but after that things are in HD quality for the duration. No issues otherwise.
American expat in Switzerland here. Using Speedtest.net I get 246.08/15.21 Mbps. I pay the cable company the equivalent of $98 USD/month for 250/15 internet service (no data caps) and cable TV (my wife likes watching US sports, so we have the "all-inclusive" TV package that includes some US sports channels). I originally had the 35/5 plan, but upgraded to the 150/10. They discontinued that plan and switched me to the 250/15 plan, which was only $5/month more.
If I wasn't satisfied with them, Swisscom (major telco) and the electric company each offer fiber-to-the-home, with up to 1000/100 speeds and no caps. There's other options for DSL too, but not nearly as fast.
Comcast, a major US ISP, has a comparably-priced plan that goes from $89/month for the first year to $119/month for the second year and then up to $148/month thereafter. They offer a bunch of TV channels and 25 Mbps internet, plus data caps. That's absurdly awful.
As an American, I find it ridiculous that wholesale bandwidth in the US (e.g. connectivity in a datacenter) is dirt cheap and fast (as an example, Hurricane Electric offers 10GigE transit for $0.45/Mbps) but that retail bandwidth available to end-users is so expensive, slow, and limited by data caps and the like. Things really need to change.
Symmetric and asymmetric keys are different things and have different key lengths. One cannot directly compare key sizes between two wholly different classes of ciphers. There are numerous reasons, mostly involving arcane mathematics, why asymmetric ciphers require longer key lengths than symmetric ciphers to offer similar levels of protection.
For example, a 1024-bit RSA key (RSA is an asymmetric cipher) is essentially equivalent to an 80-bit symmetric key (AES, 3DES, etc. are symmetric ciphers). SHA1, a hashing algorithm, provides less than 80 bits of security; those wishing stronger signatures are switching to SHA-256 (which offers 128 bits of security) and SHA-512 (which offers 256 bits).
A 2048-bit RSA key, such as those used by most CAs and web servers these days, has the same strength as a 112-bit symmetric key. NIST says they should be good enough until around 2030.
3072-bit RSA keys offer the same strength as a 128-bit symmetric key. A whopping 15,360-bit RSA key would be needed for 256-bit security; the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.
Is it wrong that I don't want my home devices to be reachable from the outside unsolicited?
Use a stateful firewall? NAT is not a firewall.
Just because something has a globally unique IP address doesn't mean that it's globally reachable.
Just another reminder to use strong passwords, password managers, and change them often. It's a pain, but it's the reality of the digital world.
What good is a password manager when the answers to your security questions are public knowledge?
Who says you need to tell the truth on those questions?
Q: "What is your mother's maiden name?"
A: "Purple monkey dishwasher."
Of course, you should keep a record of those questions and answers so you can correctly answer them if the need arises.
Of course this is about power shifting towards governments in general. This is to be expected - after all, we can't just have random people running the internet and governments happen to be the very things that represent their countries internationally
(Emphasis mine.)
Why not? That's basically what Jon Postel did: he basically singlehandedly administered the DNS root and was IANA.
Sure, things are different now, but we certainly have had random people running the internet. It worked then, why not now?
If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots. That's basically a death sentence to companies like VeriSign (rather, their cert-issuing division).
I wouldn't be too sure of that.
Of all the companies that have aided the NSA, how many are out of business or even really hurting?
Companies like what? The ones making network-tapping hardware and whatnot cater toward a limited market, not the general public. Certificate authorities directly transact with server administrators, but their primary audience are end-users and they have wide public exposure. If a CA was found to be doing shady things, browsers would remove their roots. That'd basically kill off the offending CA.
>If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots.
HAHAHAHAno. Thanks to the demon that is backwards compatibility browser vendors have implicitly or explicitly confirmed that they cannot actually revoke root certs. Or, more specifically, that many websites rely on that particular root to verify their identity and would break horribly if a root cert got revoked. i.e. revoking a misbehaving root will break the web.
Why not? There have been roots that have been revoked due to being compromised and which have issued bogus certs (e.g. DigiNotar). That's caused some chaos, but people adapted.
Sure, VeriSign is large and commands (either directly or through its subsidiaries) a substantial fraction of the CA market. Nuking it would be a Very Big Deal that browsers wouldn't take lightly, but I have no doubt that if it were shown that VeriSign (or Comodo, or other CAs) were found to be issuing bogus certs for the government to compromise people, they'd get their roots pulled by browsers. That's a death sentence for a CA, hence my skepticism in response to the proposal that they're actively assisting governments.
A better solution would be the ability to provide multiple root certs, which is not technically feasible today, and won't be for a while - even things like SSL vhosts are considered unreliable due to the prevalence of legacy browsers that don't know how to use the proper TLS extensions for hostname identification. So maybe in 10 years we can start telling site operators that they can turn on multiple certs, and 10 years after that browser vendors will have enough data to determine if it's safe to actually revoke a root cert or not. In the meantime you will have to convince HTTPS services that it's worth paying n times as much in certification costs to avoid a hypothetical root revocation.
Agreed. That would be nice.
What good is https going to be against the state? You think they can not coerce Verisign et al to hand over a copy of the root keys?
Sure, they could, but I doubt they are.
If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots. That's basically a death sentence to companies like VeriSign (rather, their cert-issuing division).
While typical users won't notice, there's still plenty of risk to getting caught, particularly when targeting anyone using major web properties: Chrome, for example, has a bunch of high-profile sites "pinned" and will report back to Google if bogus certs are being used (they identified a bunch of MITMing with compromised certs in Iran in this way). Other add-ons like Perspectives make it easier to detect if unexpected certs are showing up.
Could they get away with issuing infrequently-used certs for highly-targeted, one-off uses? Possibly, but each time they do the risk to their entire business increases.
I suspect the government would much prefer to do things sneakily in the shadows, rather than involving major CAs in such a risky role.
It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.
