Earlier quoted context omitted.
How would you solve it without HTTPS?
By signing it. "Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this. One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser woul…
ACME v2 and Wildcard Certificate Support is Live
301–310 of 321 posts
Re: ACME v2 and Wildcard Certificate Support is Live
#302Re: ACME v2 and Wildcard Certificate Support is Live
#303Earlier quoted context omitted.
Store your DNS records under revision control, and updating your records can be as simple as a "git commit && git push". https://dns-api.com/
That's pretty expensive, esp for side projects. I'm using a certbot extension for CloudFlare. Completely free.
* Those with 1 or 2.
* Those with 10-40.
I suspect lowering the price(s) on a volume-scale would allow me to find customers with 40+ domains, but at the same time I'm happy where I am and seem to have a reasonable niche.
Re: ACME v2 and Wildcard Certificate Support is Live
#304Earlier quoted context omitted.
I'm actually surprised debian repos are still HTTP. Don't get me wrong GPG signatures with pinned public key is a lot better than trust TLS of a random mirror. But isn't it nice to have two layers, the two key systems are independent and orthogonal that seems like a solid win. Need I remind of Heartbleed (openssl) or the very debian specific gpg key derivation bug years ago. There will always be bugs, we can only hop…
That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.
Majority of HTTPS traffic is sniffable and largely non-confidential, unless you pad every file and web-request to several gigabytes in size.
Does your website use gzip? Good, now padding won't help you either, — unless it is way bigger than original content. Oh, and make sure, that you defend against timing attacks as well! Passive sniffers totally won't identify specific webpage based on it's generation time, will they?!
As for authenticity… Surely, you are going to use certificate pinning (which is already removed from Google Chrome for political reasons). And personally sue certificate issuer, when Certificate Transparency logs reveal, that one of Let's Encrypt employees sold a bunch of private keys to third parties. Of course, that won't protect authenticity, but at least, you will avenge it, right?
SSL-protected HTTP is just barely ahead of unencrypted HTTP in terms of transport-level security. But it is being sold as golden bullet, and people like you are the ones to blame.
Re: ACME v2 and Wildcard Certificate Support is Live
#305Earlier quoted context omitted.
Can you elaborate as to why that would disqualify them? I don't think most of us are intimately familiar with the Baseline Requirements, or want to wade through 60-some pages to figure out your reasoning.
Three years is much too long. Last year Google's Ryan Sleevi basically said this needs to be much shorter, it takes far too long to fix anything properly with such long-lived certs. Ryan pointed out that it they couldn't get traction by agreement then Chrome can totally just be modified to count certs as expiring after 90 days and that's that. Unsurprisingly CAs did not go "OK we'll do what Ryan suggests, 90 days it…
They also pretend, that compromising 3-months certificate is "ok" (or at least less harmful, than compromising a year-long certificate), when in practice there is no reason to assume so, — 3 months is more than enough for any real-life eavesdropper.
Re: ACME v2 and Wildcard Certificate Support is Live
#306Earlier quoted context omitted.
By signing it. "Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this. One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser woul…
Sounds like you just reinvented HTTPS with a null encryption cipher. I don't see how this makes anything easier or better.
By the way, — signing is not equal to "null encryption". Signing can be done in advance, once. Signed data can be served via sendfile(). It does not incur CPU overhead on each request. Signing does not require communicating with untrusted parties using vulnerable SSL libraries (which can compromise your entire server).
As we speak, your SSL connection may be tampered with. Someone may be using a heardbleed-like vulnerability in the server or your browser (or both). You won't know about this, because you aren't personally auditing the binary data, that goes in and out of wire… Humorously enough, one needs to actively MITM and record connections to audit them. Plaintext data is easier to audit and reason about.
Re: ACME v2 and Wildcard Certificate Support is Live
#307Earlier quoted context omitted.
I don't trust any US company, so it's not any more untrustworthy for me than DigiCert, for example. I'm dropping its name because they were offering free 3-year certificates and it was the best TLS experience I've ever had.
There's a lot of countries I don't trust to keep sensitive data in. But my point is that Wosign was provably untrustworthy, rather than speculation on government interference in other CAs. I saw from your Github that you live in Kazakhstan, I would remind you the government is less than trustworthy as well[0] in regards to digital privacy. [0]: http://www.slate.com/blogs/future_tense/2015/12/14/kazakhsta...
It just coincidentally happens, that US controls 100% of root CAs and Kazakhstan (most likely) controls 0. So the later needs more audacious measures, while former can just issue a gag order to Symantec (or whoever is currently active in market).
CA system is inherently vulnerable to government intervention. There is no point in considering defense against state agents in HTTPS vulnerability model. It is busted by default.
Re: ACME v2 and Wildcard Certificate Support is Live
#308Earlier quoted context omitted.
Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening. Basically, I see it this way: - You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause th…
As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it. Consider the websites you view every day.. most of them are probably HTTPS by now. It's the wild west, basically. Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can scr…
Internet providers have been injecting ads into websites for years. Hackers and government have been doing same to executables and other forms of unprotected payload.
Hashes, cryptographic signatures, executables signing, Content-Security-Policy, sub-resource integrity — numerous specifications have been created to address integrity of web. There is no indication, that those specifications failed (and in fact, they remain useful even after widespread adoption of HTTPS).
For the most part, integrity of modern web communication is already controlled even in absence of SSL. The only missing piece is somehow verifying integrity of initial HTML page.
Re: ACME v2 and Wildcard Certificate Support is Live
#309Earlier quoted context omitted.
Three years is much too long. Last year Google's Ryan Sleevi basically said this needs to be much shorter, it takes far too long to fix anything properly with such long-lived certs. Ryan pointed out that it they couldn't get traction by agreement then Chrome can totally just be modified to count certs as expiring after 90 days and that's that. Unsurprisingly CAs did not go "OK we'll do what Ryan suggests, 90 days it…
So a bunch of centrally controlled monopolies agreed to realign their offerings to maximize profit and gain greater control over end-user. They also pretend, that compromising 3-months certificate is "ok" (or at least less harmful, than compromising a year-long certificate), when in practice there is no reason to assume so, — 3 months is more than enough for any real-life eavesdropper.
Firstly, CA/B explicitly can't talk about pricing or product offerings, because a group of businesses that collaborate on setting prices or product offerings is called a Cartel and is illegal (the example you're probably thinking of, OPEC, exists because its members are sovereign entities, and thus enjoy total immunity from the law). When they meet in person the CA/B members always begin by reading out the rules that lay out what mustn't be discussed for this reason.
Secondly, the idea is not at all that compromising 3-month certs is "ok". Instead Ryan's focus is on the pace of change. During 2016 CAs agreed to use the Ten Blessed Methods for validation, in 2017 that agreement became a concrete rule (thanks to Mozilla) but a 39 month certificate issued under the prior validation status quo would still be trusted until mid-2020.
Historically what has happened is that there's a grace period, and then CAs are supposed to go back and revoke any certificates still outstanding that break the new rules. But this is error-prone, back in early 2017 you can see the list of violations I found while checking that certificates for now prohibited "internal" names were revoked as required, each CA had excuses for why they'd missed some, but the overall lesson is that things will be mised. So Ryan doesn't want to rely on grace periods, he wants a shorter window of validity for the certificates.
MD5 and SHA-1 is the go-to example for this stuff. We expect already that SHA-2 (e.g. SHA-256 used currently in certificates) will fall the same way as the others, because it's the same construction, so we're going to be doing this again in perhaps 5-10 years. But with 39 month certificates the _minimum_ time from changing the rules to getting rid of the problem is 39 months, if it takes a few months to agree what to do, the total may be closer to 4 years. That's a very long time in cryptographic research, too long to predict what's coming. 90 days would be much better from this perspective.
Re: ACME v2 and Wildcard Certificate Support is Live
#310Earlier quoted context omitted.
LE requires setting DNS TXT records to get wildcard certs - do dynamic DNS providers ever let you do that? My assumption is they don't.
Yeah that's a fair assumption. So no wildcards for subdomains at dynamic dns providers -- probably not an important use-case anyhow.