This morning's hijack of certain AWS Route53 IPs to hijack MyEtherWallet.com


#1

Can anyone in Let’s Encrypt ops speak to whether or not there were any attempts to secure a validation for myetherwallet.com or any subdomain labels of it this morning?

If so, did this validation fail for lack of DNSSEC validation? - No - See edit

Edit 1: DNSSEC validation would not have arisen as an issue because DNSSEC is not enabled for the domain. My remaining question is whether such a validation was attempted and, if so, for what cause did it fail?


#2

Posted on mozilla.dev.security.policy’s groups:

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/2teeVLJ44RM

It seems prudent for CAs to look into this deeper and scrutinize any domain
validations reliant in DNS from any of those ranges this morning.

At least, Let’s Encrypt didn’t issued a certificate for that domain: https://crt.sh/?q=myetherwallet.com


#3

I’m the guy who started that thread on m.d.s.p

I do agree that no CA so far seems to have issued a certificate for the domain.

As these types of issues might be expected to arise more frequently, there’s an outstanding question of whether certificate authorities might end up issuing certificates to targets of this kind of attack.

In this case, there is interest in whether or not an attempt was made at securing a certificate, and if an attempt was noted, the cause for which that attempt failed could be very important. Was it because of point-of-view (network-wise) of the validation server(s)? Was it because of DNSSEC, etc?

Note: I don’t believe it would be DNSSEC in this case, as the proper host of this domain is Route53 (An Amazon service) and I don’t believe Route53 supports DNSSEC.


#4

Correct. Some customers have been asking for it for years.


#5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.