51–60 of 95 posts
Ok - here is a suggestion: The Right to root. Just as a citizens letters, papers and home are inviolable, should our new papers our new homes be also inviolable - if I own a device, No-one should legally be allowed control over it?
But yeah, if you paid for it but can't root it, you got ripped off.
Earlier quoted context omitted.
> http:// means that the endpoint has not been verified using the CA system and is using a self-signed certificate (and is thus trivially vulnerable to a MITM should certificate keys not be independently checked). Right. I understand that. The lack of certificate verification for the http scheme means that ISPs can MITM HTTP traffic with or without this proposal, just like they can with HTTP/1.1. So how does this pro…
> Really? That's a special kind of evil and should be illegal. Nah, no need to make it illegal. He's referring to AT&T's "GigaPower" gigabit service in Austin... the same service that's available from 2 other providers for the same, or cheaper, as what AT&T's charging for their data-mined bullshit. AT&T will have a fun time getting customers when Google and Grande point that out in their attack ads. :D
I've become increasingly more disgusted with IETF since I found out they have at least a few NSA agents working with them on protocols, and more importantly refusing to kick them out - even after all the Snowden revelations with NSA trying to subvert and undermine encryption protocols: http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_oper... Then I find out that they've been working with Cisco on another simil…
Ok - here is a suggestion: The Right to root. Just as a citizens letters, papers and home are inviolable, should our new papers our new homes be also inviolable - if I own a device, No-one should legally be allowed control over it?
Another stab at using 'Trusted proxies' huh? I thought we had learnt that lesson a while ago.. Can we move on please, internet?
The fact is "trusted proxies" are a real thing right now. Plenty of private networks require that you trust one or more private CA roots and all SSL are intercepted and filtered. It is sort of a pain to do. You have to use something like Microsoft System Center to push the root onto all managed computers. This IETF proposal just formalizes it.
Earlier quoted context omitted.
I believe there's already a standard HTTP header for this: Content-MD5. Browsers definitely don't cache across origins by this though. If they did, would it be possible to create a malicious JavaScript file with the same MD5 as jQuery?
Yes it would be possible because MD5 has been broken: https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities Any file can be modified to result in a hash collision with a specific MD5. This makes is unsuitable for its stated purpose as a cryptographic hash. The solution would be to use a newer and stronger hash like Keccak. A solution similar to what you are thinking of is already used by Bittorrent's Distribute…
https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability
MD5 should absolutely not be used for this content-identification purpose or any other new code... and wise designers haven't been using it for 10+ years. I'm just mentioning this to be precise about the current state of its proven weaknesses.
Is someone from the NSA behind this? Sorry, let me rephrase that. Who from the NSA is behind this?
Ok - here is a suggestion: The Right to root. Just as a citizens letters, papers and home are inviolable, should our new papers our new homes be also inviolable - if I own a device, No-one should legally be allowed control over it?
Then tech companies might start leasing out their devices: you technically don't own it, so you're not allowed to do what you want to it.
Not that the Right to Root wouldn't be nice, but the change in attitude has to come first. And we need to somehow convince the likes of Apple that their DRM is bad for business.
Er, actually reading the specification, it's about proxying http resources, not https ones. This proposal is strictly better than the transparent proxying that's common on the internet today. To distinguish between an HTTP2 connection meant to transport "https" URIs resources and an HTTP2 connection meant to transport "http" URIs resource, the draft proposes to register a new value in the Application Layer Protocol n…
HTTP/2 changes the meaning of the http:// scheme. All connections will now be TLS-encrypted. (Edit: Maybe not. See hobohacker below.) http:// means that the endpoint has not been verified using the CA system and is using a self-signed certificate (and is thus trivially vulnerable to a MITM should certificate keys not be checked out-of-band). The purpose is to provide confidentiality to the vast majority of traffic, e…
Isn't that a semantic requirement of HTTP, though? Half of the "tech" in the HTTP/1.X spec is to allow for caching of resources and responses by proxies, allowing anyone between the client and server (e.g. your ISP) to act as a CDN.
HTTPS/1.X effectively throws that away by doing end-to-end encryption. It's a trade-off: we gain the surety that all the responses are coming directly from the peer, rather than anyone else... but the web becomes 90% less cacheable, because the only places things can end up cached are between the client and the HTTPS pipe (i.e. the browser cache), or between the HTTPS pipe and the server (i.e. "reverse proxies" like Nginx.)
The current workaround for this, when you need caching for your Big Traffic on either ingress or egress, is to do what amounts to purposeful self-MITMing of your HTTPS session: to terminate HTTPS on a caching proxy, that holds the certificate of your client/server, and acts as if it were you, while itself doing another HTTPS session for "the last mile" to connect to you. This is what companies do when they deploy their own CA-cert to their networks, so everyone's access can be proxied through their own system; and this is what services like Cloudflare do when they sit "in front of" your server while not being a part of your company's VPN at all.
Basically, HTTP2 codifies this workaround, and calls it HTTP.