261–270 of 291 posts
Earlier quoted context omitted.
Presumably that's fairly new. The domain hasn't made it on the HSTS preload list shipped by browsers yet, so my guess would be they started using HSTS in response to this attack.
It was addad at most a few hours earlier and as a response to the attack. That's when I checked and it did not have HSTS at that point.
> This traffic was redirected to a server hosted in Russia, which served the website using a fake certificate — they also stole the cryptocoins of customers. What does this sentence mean? Sorry if I'm being slow. I thought the whole point of certificates is that you can't generate a legitimate one for a domain you don't control, so messing with name resolution wouldn't affect it.
Earlier quoted context omitted.
I'm trying really hard here not to be snide, but it is amazing to me that an organization that is responsible for securing the world wide web is basing that security on the hope that nobody can spoof 3 AS's at once. Just give up on BGP. Strongly suggest people use DNSSEC. For TLDs that don't support DNSSEC, require a public key issued to the registrar. You (the Certificate Authority) can get the public key from [R]WH…
We should not "give up on BGP". What we should do is to improve security in all layers. This includes BGP, and as you mention DNS. DNSSEC should be mandatory, just as TLS, for any business that take themselves seriously.
There is a major chicken-and-egg/game-theoretical problem though: any browser that does that today will piss off/irritate its users, forcing them to use other browsers or older versions of the same browser, as DNSSEC is not widely deployed on the corporate side. And until most/all browsers do something major to make the current DNS security crisis obvious to large numbers of users, most companies won't care enough to deploy DNSSEC.
At least it will be interesting to see whether, and how, this eventually gets solved.
[1] Certain abysmal DNSSEC cryptographic choices, such as 512-1024-bit RSA, should also be addressed.
Earlier quoted context omitted.
Honestly there are a lot of ways for people to foot-gun themselves when dealing with providing a service. HPKP isn't perfect, but deprecating it just for the sake of keeping some incompetent people safe is just silly. Might as well remove HSTS and not roll out Expect-CT because everything allows someone to foot-gun themselves.
The difference between HSTS, Expect-CT and HPKP is that the former two offer a way out (support HTTPS, provide qualified SCTs) whereas HPKP can effectively brick your domain for a couple of months, and it's not even hard to pull off.
If BGP is open and anybody can modify routes, why don't these attacks happen constantly? What prevents these sort of attacks and how are they fixed?
It is not open. Sane networks register prefixes. Other sane networks do not accept prefixes that are not registered to parties announcing them. If your network does not register prefixes, you need to fire them and move to someone else. If your network does not accept only registered prefixes, you need to fire them and move somewhere else. Not registering prefixes/filtering based on registrations is having sex without…
Earlier quoted context omitted.
Let's Encrypt does not currently validate from multiple perspectives but we're working on it. We're cooperating with a research team at Princeton to make sure our strategy is an effective mitigation against BGP attacks. Any given production validation right now may come from one of two of our datacenter locations, but not both. You may see multiple validation requests if you use our staging servers, but that's just a…
I'm trying really hard here not to be snide, but it is amazing to me that an organization that is responsible for securing the world wide web is basing that security on the hope that nobody can spoof 3 AS's at once. Just give up on BGP. Strongly suggest people use DNSSEC. For TLDs that don't support DNSSEC, require a public key issued to the registrar. You (the Certificate Authority) can get the public key from [R]WH…
I think this is absolutely unreasonable and damaging to me as a small player. I don't want to give my registrars more power to mess with me, they already refused to support DNSSEC on my domain because I am not using their hosting service, I don't want them to be responsible if I can get certificates of not. DNSSEC is also way too hard to set up (especially if, for example, I use OVH's name servers and another company as registrar), we need DNSSEC equivalent of LetsEncrypt's certbot for it to be usable.
This is another one of the articles that says absolutely nothing. The only reason why such attack was possible is because some of the providers did not filter announcements from hobos claiming to be able to advertise AWS space. That could have only happened if: a) AWS did not register all their policy prefixes b) providers did not apply filters on the transit announcements from those that announced AWS prefixes based…
If you think the majority of BGP speakers world-wide are applying these announcement filters you are sadly mistaken.
[1] That statement excludes Google whose idea of filtering is to let me announce anything I want and build filters based on what I announce.
Earlier quoted context omitted.
It is not open. Sane networks register prefixes. Other sane networks do not accept prefixes that are not registered to parties announcing them. If your network does not register prefixes, you need to fire them and move to someone else. If your network does not accept only registered prefixes, you need to fire them and move somewhere else. Not registering prefixes/filtering based on registrations is having sex without…
This comment is only partially true, the realities of managing customers on routers with thousands of routes precludes this careful management at the rock bottom tier-1 transit prices of the lowest common demoninators. The way HE & Cogent operate for large web-hosters at data centers is by trust and prefix-counts. The churn of various web-operators between hosting companies is massive.
Earlier quoted context omitted.
> surely browsers should shout of a certificate that was valid for domain X changes today Why? If the new cert is valid, why sound any alarms?
I visit my bank site and my browser gets a certificate for barclaysbank Ltd, to expire in 12 months. Tomorrow i visit the same site and get a different certificate, or from a different CA. Should my browser warn me? I don't know. the chances are high that 99% of people will click OK and 99% of the 1% left will look at it and think "how do i verify this?" That is probably the reason browsers don't bother with pinning…
You realize this stuff can change by the minute, nay, second?
> but still ... if I pay my landlord every week in cash and one day someone else turns up and says "hi i am your landlord, pay me" I have visual signals to warn me of a possible problem.
No, it's more like you walk into your landlord's office and there is a new secretary. Sure, usually there won't be, but it's not unheard of for companies to get new secretaries.
> I visit my bank site and my browser gets a certificate for barclaysbank Ltd, to expire in 12 months. Tomorrow i visit the same site and get a different certificate, or from a different CA.
> Should my browser warn me?
If the new cert is valid, and there are no CAA records (which, admittedly a dns hijack would make worthless), then why should the browser warn you? Everything is valid, what's wrong?
What you should be asking yourself is why we don't use mutual authentication for banks. The answer is banks think we're all idiots and couldn't handle it.
Wonder if services like Let’s Encrypt were affected. I imagine a scenario where a small hijack of DNS could allow for properly signed certificates for domains that are not owned. If I operated a CA service, I would carefully examine the requests received during this time frame. Maybe someone can audit the Transparency Logs during this period for anomalous activity.
I'm going to assume that Lets Encrypt wasn't impacted for the reason that there are several discussions that the hijacked myetherwallet website apparently had a self signed SSL cert running - and people were actually clicking through the warnings before handing over passwords. Surely they would have realised they could make the whole thing a lot more profitable if any SSL provider was impacted.