June 4th, 2016 – Emailed email@example.com and reached out on Twitter to @Comodo_SSL.
July 25th, 2016 – Robin from Comodo confirms a fix has be put in place.
That said, one should never click on links and buttons in emails. It's more comforting to be able to copy a link instead.
I made an exception for sites I was going to immediately use 1Password's autofill with, trusting its URL validation to save me from fakes. I hadn't considered that merely loading a malicious URL could cause trouble. I think I'll have to reconsider my policy on that.
I've never had a representative balk at this, but many times they'll give me a number and extension to call. But that would defeat the whole purpose. I tell them that I need a published number that I can independently confirm. Usually they just say it's fine to go ahead and use the number on their website.
None of this is foolproof. My confirmation of a phone number is usually rather cursory--a quick Google search comparing results with what I find on the company's website. But infosec crimes are becoming increasingly common and I'd rather not be the low-hanging fruit.
But at least as of today I'm pretty sure those databases are still quite expensive as that information isn't as easily available. And even if it was more readily available, it's still advantageous for criminals to maximize their payout by being selective about the accounts they rob. Who knows what information is useful to them when determining risk and benefit. Credit card numbers are a dime a dozen, but the numbers of high net worth individuals (not me, obviously!) which see less scrutiny for high-dollar purchases are worth a heck of a lot more than the ones you dump after fraudulently charging $10. If I owned a Tesla and somebody called me up to ask questions about my Tesla, I'd neither confirm nor deny; I'd politely ask them their purpose, and if it seemed legit I'd call them back on a published line. (Obviously just telling them you'd call back is all they'd need to know to profitably classify your identity, so it's very much a judgment call.)
My rule is that if I haven't previously published the information, I'm not going to give it up easily unless I initiate the communication, even if I know the information is already public, such as birth date, place of birth, etc.
My goal is just to minimize my exposure to fraud; I can never eliminate it. And choosing not to divulge personal information unless I initiate the contact, whether by phone, e-mail, or whatever, is a relatively simple, convenient, and rote countermeasure I've employed for almost a decade now.
I don't care about the technical details, except in so far as it helps me to very roughly gauge relative risk. Criminals are specialists in their area and I'm not about to pretend I can keep up with the state of the art. At the same time, fraud enterprises, like porn, tend to be at the vanguard of technology. So if something is going mainstream it's a sure bet it's been underground for awhile.
This can happen with connections between switches too, potentially; but modern (like 1980s modern) out of band signaling techniques on trunks generally prevents this type of thing.
See also Comodo vs Letsencrypt.
(DFN is the "Deutsche Forschungsnetz" ("German research network"), and it gives out sub-CAs to the individual member institutions. Which apparently is an uncommon practice)
The DFN will change this praxis while migrating to a new root certificate from "Deutsche Telekom" until 2019, but the staff at my university has major headaches. It's far more easier to document, that the members of the university should only trust (e.g. enter their password on) sites with a certificate signed by a CA with the same name as the university.
size = number of certificates signed by it (not sure from what dataset)
To read and send mail, I ssh to my mail server and use mutt there. For the most part it works great, except when I receive links I need to visit longer than about 70 characters because then I have to copy the URL in parts rather than all at once due to the plus signs inserted by mutt to indicate that the line continues.
in your ~/.muttrc will get rid of the plus signs.
While I don't believe the author is mistaken that he successfully injected HTML into the email, the email snippet quoted in the article is properly escaped, because none is needed, because the email is not HTML:
Content-Type: text/plain; charset=UTF-8
[ snip ]
<pre>This order was placed by</pre>
Content-Type: multipart/alternative; boundary="(AlternativeBoundary)"
(These are so email clients that don't support HTML — or are configured to ignore — can fall back on something.)
Web is even easier, just run chrome without pinning enabled.
I'm almost desensitized to it at this point. Despite the fact that these problems are potentially Web-breaking.
And it could have been mitigated with anti-XSS 101: rejecting all form posts containing angle-brackets.
Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.
Blacklists are only acceptable if you do it in addition to contextual encoding wherever you emit user controlled data, and even then a much stronger protection would be to whitelist acceptable characters. Either way, contextual encoding whenever you emit user data is the only real protection. --And even then it's not a good fallback protection, a strong Content-Security-Policy should be your fallback protection.
> Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.
Form posts are not the only vector for XSS, any HTTP request can be potentially exploited to perform XSS (and any part of an HTTP request), doesn't matter if it's a Form, an AJAX request, an HTTP header value, or a GET parameter, they're all potential attack vectors.
In my experience, it doesn't even cover cases such as this one, but it certainly makes developers confident they don't need to apply contextual escaping.
And "rejecting all form POSTs containing angle brackets" is definitely not the XSS 101 prevention mechanism! Don't do that.
This  is what Comodo attempted to do a while back.