231–240 of 268 posts
Earlier quoted context omitted.
Uh, a MiTM will just show an entire fake site, or it can drop your content and just send a redirect header to any website it wants.
Man in the middle attacks allow an attacker to read data over the wire. It does not mean the attacker and modify that data. It certainly doesn't mean the attacker can move traffic to a different end point.
Earlier quoted context omitted.
> and then sends it to evil.com. How would a man in the middle attack grant you that? This is the reason same origin policy exists. It is the foundation of web security. If can break SOP and prove it in a demonstration you can report this issue to Google as a defect in the top tier of their bug bounty for a sizable reward.
Without SSL, I can inject code directly into the main HTML, in the same origin context as yours.
Earlier quoted context omitted.
> The only thing that crosses the wire is a request for the application code and a response with that code. If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.
In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed. If you can break same ori…
Seriously, use HTTPS for everything. Not to be rude at all (seriously!), but it’s pretty obvious by this thread and the other you linked to that you don’t have the knowledge/experience on this topic, so do your users a favor and trust when I say you need to be using HTTPS.
[0] https://www.theregister.co.uk/2015/03/27/github_under_fire_f...
Earlier quoted context omitted.
> The only thing that crosses the wire is a request for the application code and a response with that code. If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.
In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed. If you can break same ori…
Where? I’m happy to prove the attack vector if necessary, would be trivial for me to do if the app is designed the way you described it (and no, not eligible for any Google bounty as this has nothing to do with same origin policy).
Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.
Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...
Earlier quoted context omitted.
It doesn't matter. The browser can use the SSL certificate and the corresponding public key to verify that the contents of the connection originated from the server at the domain it expects. Unless the server's private key or browser's root certificates are compromised, the connection cannot be spoofed without being detected.
You really didn't read what I wrote. If the malicious site uses the valid domain and a spoofed cert for that domain it cannot tell the difference and will establish the very same trust. The browser has no way of knowing if the requested domain is hosted from the appropriate IP address. This is all handled by the DNS system. DNS lookups and caching are not a function of the browser. Perhaps you will take it more serio…
Github pages supports TLS even for custom domains now, via Let's Encrypt. At this point, I don't think there's any excuse anymore for having a static website without TLS. Either use Github pages, or just use your favorite hosting provider and put a CDN in front of it. Note: I'm not affiliated to Github, but I've used them multiple times, and just recently discovered they now support TLS. If you want to see an example…
I’m scratching my head trying to figure out the best way to do automated certificate renewal for othe providers. It’s not like you can run certbot on a static page.
Earlier quoted context omitted.
IIRC Let's Encrypt are more strict in their validation (HTTP, DNS and SNI) than the least onerous authorities before them. The difference is that they are automated and free, but I don't think that I can get any cert I couldn't get before (either for payment or free).
No you are not correct and I've been downloaded by people that don't know the history of DNS Certification Authority Authorization (CAA), which became required in 2017. Let's Encrypt launched 2016, which meant that unless you were doing HPKP with long pin times and had traffic that already had hit your endpoint, if someone was on your gear (but lacked your private key) they could impersonate you for free and with no…
The browsers do show some things for better verified certificates e.g. "YOUR BANK LTD." on a banks cert, "Secure" on hacker news/My page secured with let's encrypt.
So controlling traffic on the domain is really sufficient for the promise that LE is trying to make to you which is "When I accessed this domain, the entity that owns this key controlled the traffic. I don't really know anything about the entity."
If you think that presents a vulnerability then it's because you're equating https with entity verification (and I don't blame you because the browsers have trained us to do this)
When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…
Pretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.
https://github.com/certbot/certbot/issues/1301
Not to worry though, there are over 100 other ACME clients that I can choose from.
Earlier quoted context omitted.
IIRC Let's Encrypt are more strict in their validation (HTTP, DNS and SNI) than the least onerous authorities before them. The difference is that they are automated and free, but I don't think that I can get any cert I couldn't get before (either for payment or free).
No you are not correct and I've been downloaded by people that don't know the history of DNS Certification Authority Authorization (CAA), which became required in 2017. Let's Encrypt launched 2016, which meant that unless you were doing HPKP with long pin times and had traffic that already had hit your endpoint, if someone was on your gear (but lacked your private key) they could impersonate you for free and with no…
It's disingenuous to call this certificate forgery. If your gear is owned or somebody is in a position to perform active MITM on you, then WebPKI doesn't give a damn about your situation to begin with. It's not part of the security model they're concerned with. DV does exactly what it says on the label, and Let's Encrypt did nothing to change that.