191–200 of 291 posts
> That BGP hijack allowed the hacker to redirect the miners’ computers to a malicious server controlled by the hijacker.
Also, the entire blockchain ecosystem is very susceptible to BGP hijacks [1]
[0]:https://www.wired.com/2014/08/isp-bitcoin-theft/ [1]:https://btc-hijack.ethz.ch/
This same attack can be used to generate valid TLS certs for any website, for example using Let's Encrypt. The best part? Your target doesn't need to use Let's Encrypt at all. Anyone can use them to forge certs for any domain . Of course, this is possible with most other cert providers, but Let's Encrypt automates it. So.... TLS certs mean jack squat if you can pull off a BGP+DNS attack. You might want to start pinni…
What's also interesting is in the comments someone stated they'd used a Godaddy certificate issued on april 7. Maybe they had access to their account, or Godaddy's internal systems?
I'm the GM for Security Products at GoDaddy, responsible for the GoDaddy CA. I have checked with the team and do not see any certificates issued to: http://myetherwallet.com/ (including DV).
If someone has an image of what was seen, please send it to me at tperez@godaddy.com so that we can investigate further.
Thanks
Tony
It's sad that HPKP is being deprecated. It's one of the best ways to defend against an attacker with bgp hijack capabilities assuming you pin your own public key. Difficult to scale though and prone to disastrous misconfiguration.
Too many people have foot-gunned themselves with that one. As someone who has to readily fight technical fires for other people (when they should have googled their problems) I am glad to see HPKP go.
Earlier quoted context omitted.
Too many people have foot-gunned themselves with that one. As someone who has to readily fight technical fires for other people (when they should have googled their problems) I am glad to see HPKP go.
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.
Earlier quoted context omitted.
If I control the network, I can strip off any security that might be in DNS. I can change or remove CAA records, DNSSEC, etc. Those things currently fail open, which exception to DNS replication which will take "refresh" time to fail. I can then get new certs for the DNS I now control. HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the clien…
One could argue that in a perfect world the combination of DNSSEC and CAA should stop attacks of this nature. However, this only holds up under a rather limited set of circumstances: 1. The targeted domain would need to make use of both DNSSEC and CAA in the first place. I doubt that's true for more than a tenth of one percent of all domains out there. 2. The attackers would have to only target DNS resolution, and no…
"All issuances under example.com shall first be approved by telephone call to our security office on 1-234-567-8900, and the certificate issued shall have a notBefore timestamp no earlier than 24 hours after an SCT included in the certificate"
This requires no new technology that I can see. If CAA and DNSSEC work together as intended (which I admit is a big "If" but they can and should) the Bad Guys now need to mess with the phone system for approval, then wait past the MMD and hope you aren't watching for their shenanigans. Or break into a CA and issue for themselves. That's a much higher bar, albeit at great cost.
Earlier quoted context omitted.
If I control the network, I can strip off any security that might be in DNS. I can change or remove CAA records, DNSSEC, etc. Those things currently fail open, which exception to DNS replication which will take "refresh" time to fail. I can then get new certs for the DNS I now control. HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the clien…
> HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the client, such as mobile apps. I thought HPKP is TOFU, not (necessarily?) preloaded? Meaning you don't need to control the client for the client to be able to take advantage of it?
Surely related (and warning!): During this period I received an email from: ship-confirm@amazon.com purporting to notify me of the despatch of a non-existent order; with an attached .zip. Nothing about the message, except the .zip and suggestion of an order's existence, was at all suspicious - all links point to amazon.com. I checked on amazon.com (without following a link) and on amazon.co.uk (where I would usually…
Earlier quoted context omitted.
If you are using DNSSEC, hopefully the issuers are validating it.
I'm not able to find any information on Let's Encrypt and DNSSEC validation. Anyone know if they validate it?
Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert. Here a few ways I can think of to make this harder for an attacker: * Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP). * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing th…
Warning: this is only to be used by experts. Otherwise, your site is going to become permanently/long-term inaccessible by the browser if you screw up just once.