Malvertising Campaign Used a Free Certificate From Let's Encrypt (csoonline.com)

← Back to Stories (view on slashdot.org)

Malvertising Campaign Used a Free Certificate From Let's Encrypt (csoonline.com)

Posted by timothy on Thursday January 7, 2016 @02:37AM from the oh-do-let's dept.

itwbennett writes: On Wednesday, Trend Micro wrote that it discovered a cyberattack on Dec. 21 that was designed to install banking malware on computers. The cybercriminals had compromised a legitimate website and set up a subdomain that led to a server under their control, wrote Joseph Chen, a fraud researcher with Trend. The subdomain used an SSL/TLS (Secure Sockets Layer/Transport Layer Security) certificate issued by Let's Encrypt, the first large-scale project to issue free digital certificates. which is run by the ISRG (Internet Security Research Group) and is backed by Mozilla, the Electronic Frontier Foundation, Cisco, and Akamai, among others. The incident has sparked disagreement over how to deal with such abuse, writes Jeremy Kirk.

123 comments

Min score:

Reason:

Sort:

Why the emphasis on Lets Encrypt? by Richard_at_work · 2016-01-07 02:43 · Score: 5, Insightful

This style of attack would have been able to get an SSL cert from most cheap cert providers, as most of the cheap ones only require you to dump a particular file in the right place on the website for verification, so why the emphasis on "Lets Encrypt"? Because they are "cheaper than cheap"?
1. Re:Why the emphasis on Lets Encrypt? by QuietLagoon · 2016-01-07 02:59 · Score: 5, Informative
  
  The emphasis on Let's Encrypt is misplaced.
  .
  Unlike most other CA's, Let's Encrypt has a very short lifetime on their certs (60 days, I believe) so that an abused cert quickly falls out of the eco-system. I've read that Let's Encrypt eventually wants to shorten that lifetime even more, to 30 days.
  Most other CAs have cert lifetimes of a year (or longer). Then the question surfaces - how useful is cert revocation? Do all TLS clients check for cert revocation?
2. Re:Why the emphasis on Lets Encrypt? by mi · 2016-01-07 03:02 · Score: 1
  
  This style of attack would have been able to get an SSL cert from most cheap cert providers
  It used to be, one had to prove being "a legitimate business" to obtain an SSL certificate. But you are right, that proliferation of cheap — and therefore not caring — CAs has devalued it.
  
  Because they are "cheaper than cheap"?
  Yes. As long as some kind of payment is required, it is usually possible to identify the buyer. This possibility itself is a deterrent...
  I am all for the ability to remain anonymous, but we must realize, that anonymity can be abused — otherwise we'll lose what little of it remains to more knee-jerk reactions.
  
  --
  In Soviet Washington the swamp drains you.
3. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:04 · Score: 1
  
  Perhaps it's because Trend Micro sells certs...
4. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:10 · Score: 3, Informative
  
  The lifetime at launch is actually 90 days (https://letsencrypt.org/2015/11/09/why-90-days.html)
  The rest is correct.
5. Re:Why the emphasis on Lets Encrypt? by QuietLagoon · 2016-01-07 03:11 · Score: 1
  
  Thanks for the correction.
6. Re:Why the emphasis on Lets Encrypt? by Medievalist · 2016-01-07 03:14 · Score: 5, Informative
  
  Most other CAs have cert lifetimes of a year (or longer). Then the question surfaces - how useful is cert revocation? Do all TLS clients check for cert revocation?
  Most SSL/TLS clients do not check for a relevant CRL. The few that do (such as Firefox and other web browsers) typically require configuration and won't check for revocation by default out of the box.
  In contrast, nearly all SSL/TLS clients that I am aware of (certain MTAs being an exception) will refuse to use an expired certificate unless specifically instructed to do so by the end user. So expiration is more likely to have an effect than revocation.
7. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:21 · Score: 1
  
  Primarily because the for-profit CAs would simply revoke a certificate that was issued fraudulently. From the Trend Micro blog:
  
  In this particular case, the attackers created ad.{legitimate domain}.com under the legitimate site.
  I don't really follow Lets Encrypt's logic here of why they won't revoke the certificate. It seems their only argument is that "there's other ways to deal with the problem". Which is true, but I don't see why taking multiple approaches isn't a good idea.
  If the certificate had been fraudulently obtained for an existing domain that can't simply be listed as a spam domain (Let's say www.amazon.com), would Lets Encrypt also refuse to revoke the cert? Obviously you can't list www.amazon.com as a fraudulent domain.
8. Re:Why the emphasis on Lets Encrypt? by QuietLagoon · 2016-01-07 03:21 · Score: 2
  
  ...Yes. As long as some kind of payment is required, it is usually possible to identify the buyer. This possibility itself is a deterrent... ...
  Bitcoin has changed that aspect of the algorithm.
  Additionally, more traditional pay methods have become so automated and inexpensive to use that it is quite easy to change payment methods on a frequent basis, effectively making tracing worthwhile only for the most egregious offenses.
9. Re: Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:27 · Score: 0
  
  This has nothing to do with letsencrypt, nor the ability to be anonymous. There will always be attacks upon anything which one desires to be secure and is yet one more reason to not only HAVE the ability to BE anonymous but to also raise the awareness upon the need for widespread use of encryption worldwide. I think this is just a feather in the cap for lets encrypt and yet one more wake up call for securely encrypted everything for everyone fucking everywhere.
10. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:35 · Score: 1
  
  " so why the emphasis on "Lets Encrypt?"
  Cheap shot at a competitor, nothing more.
11. Re:Why the emphasis on Lets Encrypt? by tepples · 2016-01-07 03:40 · Score: 1
  
  It used to be, one had to prove being "a legitimate business" to obtain an SSL certificate.
  True, TLS certificates were originally supposed to be organization-validated. But in the original model, how was the hobbyist operator of a web site supposed to protect passwords of the site's users from eavesdropping?
12. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:54 · Score: 0
  
  And they suggest the renewal to happen ~30 days before expiration.
13. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 03:58 · Score: 1
  
  That's true; nobody really minds Anonymous Coward, but Anonymous Criminal is another story, as is Anonymous A-hole.
14. Re:Why the emphasis on Lets Encrypt? by mi · 2016-01-07 04:11 · Score: 2, Informative
  
  But in the original model, how was the hobbyist operator of a web site supposed to protect passwords of the site's users from eavesdropping?
  The original model was meant to facilitate online commerce. Netscape invented SSL and was pushing it despite the opposition from IPsec proponents — because SSL-certificates were to provide assurance, that the remote end is a legitimate business. One may argue, the encryption aspect was secondary.
  If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.
  
  --
  In Soviet Washington the swamp drains you.
15. Re:Why the emphasis on Lets Encrypt? by codealot · 2016-01-07 04:13 · Score: 1
  
  The certificates from Lets Encrypt (and other commonly used cheap providers) are "domain validated", which is the lowest rung of site certificate. These are perfectly okay for everyday use on Internet sites that don't process highly sensitive data.
  The best consumers can do is demand extended validation certificates for their banking sites, and each time you connect to your bank's site verify you are using an EV certificate.
16. Re:Why the emphasis on Lets Encrypt? by Opportunist · 2016-01-07 04:13 · Score: 1
  
  30 days, 60 days, 90 days, whatever. The average life span of a trojan before it gets detected even by MS Defender is 3 days, tops.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
17. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 04:55 · Score: 0
  
  Still kind of lame. As you noted, it's actually 90 days. So that's 90 days that an attacker can use a fraudlent cert. How is that OK? It's not really about whether ALL browsers check revoked certs, but whether enough for this to be useful. I'm fairly certain that the major browsers have check for certificate revocation for a long time. How is that not useful?
  Let's Encrypt response is stupid. If they can automate creating signed certs, they can automate revoking them. What's the big deal?
18. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 05:06 · Score: 2, Informative
  
  CRL's are of limited usefulness anyway. There is no guarantee that the attackee will be able to contact the CRL site and everyone defaults to trusting the revoked cert in this case.
  Posted AC to preserve mods
19. Re:Why the emphasis on Lets Encrypt? by luvirini · 2016-01-07 05:07 · Score: 1
  
  The emphasis on Lets Encrypt is likely because that way Trend Micro will get more visibility for "the new thing is bad". Trying to say "the old thing is bad" mostly causes yawns though it is a known problem.
  So simply: marketing.
20. Re:Why the emphasis on Lets Encrypt? by darkain · 2016-01-07 05:18 · Score: 2
  
  They HAVE automated revoking of certs. The revoking happens by the owner of the cert though (in this case, the attacker). How would you automate the process of revoking otherwise, especially in a way that doesn't cause false positives which would render websites unreachable by clients?
21. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 05:19 · Score: 0
  
  Blockchain is likely traceable. It seems to be computationally expensive, but it's not like you gotta solve anything hard- the blockchain is a ledger, after all, so tracing transactions backwards is certainly possible.
22. Re:Why the emphasis on Lets Encrypt? by darkain · 2016-01-07 05:22 · Score: 2
  
  "CAs has devalued it"
  The values have shifted, not become less. The value used to be in verification of business. Now, partly thanks to the NSA, the value is more in encrypting all possible web traffic. There are enough major organizations that all collectively agree that encryption is more valuable than the bottom line at this point that Let's Encrypt can give out certs for free.
23. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 05:40 · Score: 0
  
  Which is easy to do since EV certificates are the only one with the Green Bar.
24. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 05:49 · Score: 0
  
  Why the emphasis on Lets Encrypt? Better click-bait?
25. Re:Why the emphasis on Lets Encrypt? by DarkOx · 2016-01-07 06:34 · Score: 4, Informative
  
  If it is only a small part of data, that actually needs encryption â" the password and the credit card number â" you can do that (using the well-known and studied protocols) in JavaScript.
  No you can't do that, no stop right right WRONG.
  The JavaScript itself must be delivered on a authenticated encrypted channel because if it isn't how will my browser know its not supposed to run that XMLHttpRequest call to post a second plan text copy of that info to evil-hacker.com after you main in the middle my amazon session in the coffee shop.
  Same goes with forms that are delivered over http but post https, this wrong and dangerous for the same reason. You can do authentication and encryption in the application layer if its a fat client and the client already has a static copy of trusted code form elsewhere but in the case of web site where the 'application' is being downloaded from the server the client needs a way authenticate and ensure transport integrity while obtaining the application itself otherwise its game over, your pwnd before you begin. The network layer is the correct place.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
26. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 06:53 · Score: 1
  
  The certificate in question was used to distribute banking malware. I doubt its creators would have any qualms with using a stolen payment method.
27. Re:Why the emphasis on Lets Encrypt? by Bert64 · 2016-01-07 06:55 · Score: 1
  
  Or this style of attack could be performed by using an SSL cert that was already present on the hacked server...
  
  --
  http://spamdecoy.net - free throwaway anonymous email - avoid spam!
28. Re: Why the emphasis on Lets Encrypt? by TuballoyThunder · 2016-01-07 08:21 · Score: 1
  
  Unfortunately, as Firesheep demonstrated, any user authenticated (e.g. username/password) session over HTTP needs to be encrypted the entire duration. Switching between https and http is a security vulnerability.
29. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 09:38 · Score: 0
  
  Yes, this is about Trend Micro trying to grab onto the New New Thing in the hopes of appearing relevant.
  I am a past Trend Micro employee. Last week I received something from their Irving TX office, the envelope has my address but someone else's name (nothing about this name matches mine, not even first letters). I am forced to conclude that Trend Micro can't work databases.
30. Re: Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 11:07 · Score: 0
  
  Wow, what junk I could self sign and be more trustworthy than disposable certs.
31. Re: Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 11:13 · Score: 0
  
  That's just so totally pointless, the least they could do is elicit the r/e crowd to help them audit and provide longer term certs.
  But then again, that'd be vulnerable to the same shell game as malvertising tricks.
32. Re:Why the emphasis on Lets Encrypt? by mars-nl · 2016-01-07 12:31 · Score: 2
  
  If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.
  If... I personally would like to have everything encrypted, such as what I read on Slashdot or on Wikipedia.
33. Re:Why the emphasis on Lets Encrypt? by mars-nl · 2016-01-07 12:33 · Score: 1
  
  Or maybe they sell web security software that relies on unencrypted HTTP connections to detect malware.
34. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 13:29 · Score: 2, Informative
  
  The cert wasn't issued fraudulently. The domain validation is totally legit seeing as the attackers had control of the domain.
35. Re:Why the emphasis on Lets Encrypt? by Bengie · 2016-01-07 13:54 · Score: 1
  
  Revoking certs is expensive. Clients must store a list of every revoked cert that are still valid. If creating a cert is free, one could just create a bunch of certs and revoke them, which would quickly overwhelm clients ability to track revoked certs. Especially embedded devices with limited memory and storage.
36. Re:Why the emphasis on Lets Encrypt? by Bengie · 2016-01-07 13:59 · Score: 1
  
  The point of certs is not to blindly trust a cert because someone has one, it's to trust the cert is the cert it claims to be. The North Korea government could have a cert for all I care, but I'm not going to trust their site, even if I trust their cert.
37. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-07 17:28 · Score: 0
  
  because lets encrypt are refusing to revoke certs for malware sites. They're on a fast track to getting their root certs removed from everything. Good luck to them. Anyone got instructions on how I can remove their certs?
38. Re:Why the emphasis on Lets Encrypt? by arglebargle_xiv · 2016-01-07 22:05 · Score: 1
  
  Most SSL/TLS clients do not check for a relevant CRL.
  And that's the important point in this case, revocation doesn't work so why bother? Other CAs go through the pretense (well, if enough pressure is put on them, typically via public shaming, mostly they ignore misuse of certs), while Lets Encrypt has made a sensible policy decision not to bother.
  A more amusing issue is the current discussion on one of the Mozilla lists about what to do about Kazakhstan's request to get their MITM CA cert included in the browser's list of trusted CAs.
39. Re:Why the emphasis on Lets Encrypt? by mi · 2016-01-08 04:44 · Score: 1
  
  I personally would like to have everything encrypted, such as what I read on Slashdot or on Wikipedia.
  IPSec was supposed to do that. But appearance of SSL nipped IPSec' spread in the bud. And the revanche attempts by IPv6 are so far faltering.
  
  --
  In Soviet Washington the swamp drains you.
40. Re:Why the emphasis on Lets Encrypt? by mi · 2016-01-08 04:50 · Score: 1
  
  JavaScript itself must be delivered on a authenticated encrypted channel
  Yes, but this download can arrive from an SSL-using server run by a company big enough to actually have its certificate application properly validated. Think jquery.js.
  The question was not, whether SSL is needed at all, but how can a small operator secure logins without going through the extensive and expensive validation originally envisioned for SSL-certificates.
  
  --
  In Soviet Washington the swamp drains you.
41. Re:Why the emphasis on Lets Encrypt? by Anonymous Coward · 2016-01-08 10:23 · Score: 0
  
  I personally would like to have everything encrypted, such as what I read on Slashdot or on Wikipedia.
  First, Slashdot would have to start serving pages over HTTPS... Kinda sad that this isn't happening.
42. Re:Why the emphasis on Lets Encrypt? by DarkOx · 2016-01-09 11:14 · Score: 1
  
  No that does not solve the problem. Because if I am getting the main page over http, and I am the victim of an MITIM attack than the attacker can alter the page to source jquery.js from a site they control. Without or without SSL itself.
  Actually what you describe is worse! Unlike the more general situation where the attacker needs somehow needs to modify page content he does not probably know about ahead of time (assuming he just wants to get any access to my stuff not just a specific site) he got to do this on the fly quickly enough I don't notice anything wrong. That will be a hard problem.
  A site that use big shared popular js libraries on the other hand is way more vulnerable. His proxy can probably use a simple regex to replace lines where they are sourced. His altered libraries can constructed to just send whatever data they can get a hold of, his attack probably will work against many sites.
  So no you really must authenticate the fist party site, or its game over.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
43. Re:Why the emphasis on Lets Encrypt? by mi · 2016-01-09 18:20 · Score: 1
  
  Well, you just described, why the whole ssh thing — which you download from somewhere to then run — is not secure... Is it?
  I suppose, you trust the source of the ssh-distribution — you'd need a similar trust in the source of my hypothetical JS-library.
  
  So no you really must authenticate the fist party site, or its game over.
  ssh does not give you that either — not on the first connection. Unless the remote's fingerprint is published in a (secure) DNS. Khmm, maybe, that'd be the alternative for the small operators?
  Yes, this really is me, but whether I am a legitimate business — that remains a question.
  
  --
  In Soviet Washington the swamp drains you.
Well of course it did! by Anonymous Coward · 2016-01-07 02:46 · Score: 0

You give people free shit, and they make shit out of it!
You can try to impose your moral fucking bullshit on your free shit, but then it won't be free anymore, now will it?
Fucking hypocritical morons.
1. Re:Well of course it did! by Anonymous Coward · 2016-01-07 02:52 · Score: 1
  
  It must be true. Slashdot has given you a free place for you to spew your shit.
2. Re:Well of course it did! by Opportunist · 2016-01-07 04:15 · Score: 1
  
  Yeah, Linux is such a piece of dung...
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Inevitable by The-Ixian · 2016-01-07 02:49 · Score: 3, Interesting

I think that one way to deal with this would be in the browser.
Currently, EV certs will turn the address bar green or have some other indication above and beyond the normal "lock" icon.
Perhaps we need to have a different color or indication for each kind of cert.
Also, perhaps have a warning in the browser if the last known certificate is from a different CA and/or has a different validation level from the certificate currently being presented by the same domain.
Other than that, I am not sure what could be done on the server side of things. The system is meant to be free and open... which, by definition, means it is going to be abused.

--
My eyes reflect the stars and a smile lights up my face.
1. Re:Inevitable by Aaden42 · 2016-01-07 03:00 · Score: 1
  
  Given the number of users who can be fooled into thinking a site is "secure" just by having an image of a key appearing somewhere on the page (not the browser chrome, but actually in the HTML of the site), what's the point of adding more chrome?
  I doubt most users are capable of understanding the concept of chain of trust nor levels of verification behind different certificates. I'm positive that capabilities aside, the vast majority don't want to learn the difference and willfully avoid learning.
2. Re:Inevitable by Anonymous Coward · 2016-01-07 03:01 · Score: 0
  
  The majority of internet users aren't going to pay attention even if their address bar flashes like a rave. For the majority of users, most of whom are the ones that would fall for faked sites in the first place, it needs to have little to no reliance on the user.
3. Re:Inevitable by Anonymous Coward · 2016-01-07 03:01 · Score: 0
  
  The system is meant to be free and open... which, by definition, means it is going to be abused.
  Your definition of free and open differs substantially from mine.
4. Re:Inevitable by The-Ixian · 2016-01-07 03:29 · Score: 1
  
  I just don't buy into this 100%
  I think that if you take the time to explain the importance of something and relate it to something they care about (like not getting their important files held ransom, for example) they will listen. It is just about making it easy to understand.
  Now, I have personally met users who are willfully ignorant. I think they are the minority though.
  
  --
  My eyes reflect the stars and a smile lights up my face.
5. Re:Inevitable by Anonymous Coward · 2016-01-07 03:31 · Score: 0
  
  The system is meant to be free and open... which, by definition, means it is going to be abused.
  Your definition of free and open differs substantially from mine.
  Which still doesn't prove that you are right and I am wrong.
6. Re:Inevitable by The-Ixian · 2016-01-07 03:32 · Score: 1
  
  Ok, you are right. abuse is not the definition of "free and open".
  What I meant to say was that free and open systems tend to be abused. Think public restrooms...
  
  --
  My eyes reflect the stars and a smile lights up my face.
7. Re: Inevitable by ljw1004 · 2016-01-07 04:44 · Score: 1
  
  Are you the same guy who invented the five-color terror alert scale and no one knows what the different colors mean?
  We have a puce alert in the browser bar!
8. Re:Inevitable by Anonymous Coward · 2016-01-07 05:24 · Score: 0
  
  I think that if you take the time to ex
  Yeah yeah blah blah show me the titties, I clicked titties.jpg.exe I demand my titties!
9. Re:Inevitable by Anonymous Coward · 2016-01-07 05:42 · Score: 0
  
  Since this was only a domain valided domain, shouldn't the absense of the green address bar be a big enough hint?
10. Re:Inevitable by Anonymous Coward · 2016-01-07 06:45 · Score: 0
  
  Other than that, I am not sure what could be done on the server side of things. The system is meant to be free and open... which, by definition, means it is going to be abused.
  Correction, not "going to be abused", but instead "very slightly lowers the bar for existing abuse that has been going on for decades"
  All Lets Encrypt really enables are the script kiddies in moms basement too poor to spend the $50 for a cert from anywhere else.
  $50/year as an operating expense for any other blackhat ring or sponsored hacking group is nothing.
  They spend many hundreds PER MONTH registering new domains to host their malware, knowing they have only a couple days before said domains get blacklisted. Nor do they mind "wasting" the extra 360 days of payment remaining on those domains.
  They make exponentially more income than that for their crimes.
  They have already been doing this since time began (Well, since CA's began in the 80s anyway)
  StartSSL has had free certs for a number of years, you just have to manually renew them every 12 months.
  Lets Encrypt certs last 1 month but are auto-renewed so long as your signin is in good standing. Reporting abuse should be what takes care of that.
  Unfortunately I can't get the cso online site to load for some reason however, so can't see the exact complaint being made against the abuse reports.
  Obviously if Lets Encrypt is not handling such things according to standard or their own statements, then yes that's a problem and needs fixed.
  But that is true for any CA. DigiNotar at first used to ignore such abuse reports too. Of course they also issued fake certs for existing domains too, and became discredited and removed from browsers.
  That option is always available for Lets Encrypts cross-signed root cert as well if need be. Hopefully it doesn't need to come to that and either the complaints are bogus or if they are true then they clean up their act, whatever is needed.
11. Re:Inevitable by Bert64 · 2016-01-07 07:00 · Score: 1
  
  It's not even the cost aspect, a criminal gang is unlikely to think twice about paying for a certificate fraudulently (e.g. with stolen card details).
  
  --
  http://spamdecoy.net - free throwaway anonymous email - avoid spam!
12. Re:Inevitable by Anonymous Coward · 2016-01-07 07:23 · Score: 0
  
  Perhaps we need to have a different color or indication for each kind of cert.
  A primary rule of interface design is NEVER to use color as the sole means of conveying information. Doing so means that the blind, elderly, and colorblind population will be unable to receive the intended message. Any design that knowingly leaves 20%+ of the users unable to decipher the message is poor by any definition.
13. Re:Inevitable by Alumoi · 2016-01-07 08:33 · Score: 1
  
  I just don't buy into this 100%
  I think that if you take the time to explain the importance of something and relate it to something they care about (like not getting their important files held ransom, for example) they will listen. It is just about making it easy to understand.
  Now, I have personally met users who are willfully ignorant. I think they are the minority though.
  Well, last time I checked Failbook still has a lot of losers. So, no, you may explain until you turn blue, if the user wants the cute cat picture, the user will get it, no matter what.
14. Re:Inevitable by PhunkySchtuff · 2016-01-07 08:55 · Score: 1
  
  How would you suggest breaking down the different types of certificates to assign them a security level? By the price of the certificate? By the rigour of the verification?
  Technically there's no difference between a $0 Lets Encrypt cert, a $5 SSLs.com cert or a $250 Symantec cert - they are all basic SSL certificates and all use similar methods for domain verification (either put a named file in the root of your website, add a particular DNS entry to your domain or reply to email sent to webmaster@ postmaster@ or hostmaster@)
  Then there are the green EV certs - they do undergo more rigorous verification of domain ownership, but then they already get the green address bar. When some of the biggest names on the internet, even those that run their own CAs, don't use EV certs, you have to ask yourself what the value is in them?
  Does anyone really care if the address bar is green or not? Would anyone notice if one day they went to, say, Symantec.com and the address bar wasn't green?
  
  --
  Specialist Mac support for creative pros, Melbourne
15. Re:Inevitable by AmiMoJo · 2016-01-07 22:30 · Score: 1
  
  The UI is wrong. Secure should be the default, what we want is to indicate insecurity. Normal HTTPS connections should be white, and unencrypted HTTP red. Reserve green for enhanced certs.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Great Response by Anonymous Coward · 2016-01-07 03:00 · Score: 5, Informative

This article looks like a really good response to the issue: https://unmitigatedrisk.com/?p=552
1. Re:Great Response by Anonymous Coward · 2016-01-07 03:38 · Score: 0
  
  +1 -- This deserves much more attention here.
2. Re:Great Response by Anonymous Coward · 2016-01-07 11:58 · Score: 0
  
  It would get more attention with a working link and a brief summary.
Misundering what certificates certify by Anonymous Coward · 2016-01-07 03:01 · Score: 0

The problem here seems to be that people are assuming that a certificate means more than it actually does. The certificate certifies the identity of the site and gives no information about the contents or reliability of the site.
1. Re:Misundering what certificates certify by Anonymous Coward · 2016-01-07 03:35 · Score: 1
  
  The problem here seems to be that people are assuming that a certificate means more than it actually does. The certificate certifies the identity of the site and gives no information about the contents or reliability of the site.
  Meanwhile, as everyone is busy debating the pro and con of certificates, the bigger issue is ignored:
  "The cybercriminals had compromised a legitimate website and set up a subdomain that led to a server under their control"
  As long as there are "legitimate" websites who don't give two shits about security, certificates are meaningless.
2. Re:Misundering what certificates certify by Opportunist · 2016-01-07 04:16 · Score: 1
  
  The problem is that for the longest time we've told people to look for that all-powerful HTTPS encryption with the green icon next to it saying that it's really what it claims to be.
  Can't really shift the blame on that one.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Why we cannot have nice things.. by wbr1 · 2016-01-07 03:02 · Score: 4, Interesting

The ISRG is both right and wrong. CAs cannot respond fast enough and likely do not have enough information to vet requests for new certificates fully. However, once a cert is used in bad faith it should be revoked.
The ad brokers do not care that bad ads slipped in as they make money on any, so they have zero incentive to remove malvertising other than a cursory effort to appease the lawyers and government.
This is why I install adblocks on all customer machines now (and we process a large amount). To an end user advertising of of limited utility, and comes with at minimum high annoyance and at worst malware/fraud/id theft.
Case in point, I was trying to find news information on a police standoff near my house, and one of the official local news stations ads were targeting nexus 6 with a scam 'free iPad' redirect. This only occurred on my Nexus 6, not a PC or LG phone. This is just normal day to day browsing, and I could not even read the news.
The state of affairs when it comes to online advertising and scams is very bad and will kill the industry very soon if changes are not made. Unfortunately it will likely bring down many good sites for real content with it.

--
Silence is a state of mime.
1. Re:Why we cannot have nice things.. by Anonymous Coward · 2016-01-07 03:13 · Score: 0
  
  However, once a cert is used in bad faith it should be revoked.
  If I'm not mistaken, the legitimate owner of the server can have a revocation issued using the let's encrypt tools. So I'm guessing that the discussion is about whether or not let's encrypt should revoke certificates *on their own* when it becomes knows that they are used for unwanted things. Which of course raises the question of who gets to decide what is unwanted.
2. Re:Why we cannot have nice things.. by turbidostato · 2016-01-07 03:17 · Score: 1
  
  "CAs cannot respond fast enough and likely do not have enough information to vet requests for new certificates fully."
  They used to. The problem is not that they can't, the problem is that they learned that the end user neither understands nor cares for proper verification, so why they should pay care when that means less business and higher costs?
3. Re:Why we cannot have nice things.. by RogueyWon · 2016-01-07 03:21 · Score: 1
  
  Any sane ad-broker has a very good reason to care about malvertising and to put a lot of resource into filtering it out - and you identify it in your own post.
  The rise in malvertising is serving as a huge driver for the use of adblockers. Moreover, while early adoption of adblockers was mostly by well-informed home and small-business users, the rise of malvertising means that major corporate and Government networks are increasingly switching to adblock-by-default. Which in turn means that a lot of less-informed users are becoming aware that adblockers exist and make web-browsing a much more pleasant experience.
  If ad-brokers don't get serious about stopping malvertising, then they may find themselves pushing their ads out into the void. Frankly, they may already have left it too late...
4. Re:Why we cannot have nice things.. by QuietLagoon · 2016-01-07 03:26 · Score: 1
  
  ...The state of affairs when it comes to online advertising and scams is very bad and will kill the industry very soon if changes are not made. ...
  Exactly correct.
  .
  The whole online advertising technical model is little more than an unfettered and insecure conduit deep into the personal ecosystem of people on the Internet.
  The system was developed and is run by people who are more concerned about the number of hits an ad gets than about the security of the person's device into which they have intruded.
5. Re:Why we cannot have nice things.. by Anonymous Coward · 2016-01-07 03:38 · Score: 0
  
  Any sane ad-broker has a very good reason to care about malvertising and to put a lot of resource into filtering it out .
  Sane ad-broker . . . LOL . . . . LOL . . . is that sort of like an honest lawyer?
  Ad brokers are scum who have no legitimate reason to exist and they are the reason that malicious advertising is getting worse.
6. Re:Why we cannot have nice things.. by Anonymous Coward · 2016-01-07 04:10 · Score: 0
  
  That's an interesting question... I don't think the owner of the server can revoke the certificate, only the owner of the key that was used to register it can do it.
  https://tools.ietf.org/html/dr...
7. Re:Why we cannot have nice things.. by guruevi · 2016-01-07 04:44 · Score: 1
  
  The only reason a CA would revoke a cert on it's own is if it were assigned to someone who didn't have the rights to request it. Eg. if they sign a cert for google.com to someone who doesn't control google.com at the time of signing.
  This is different, these criminals had control over a subdomain and used it to forward it to their own domain which was in turn encrypted with SSL. The criminals had control over their domain and used an SSL certificate on their domain. The idiots at the bank or whatever allowed their domain and subdomain to be controlled and forwarded to a third party, that's the main issue.
  A CA should not be in the business of censoring, they are in the business of signing certificates. All criminals use encryption and this kerfuffle is just a call for governments to be allowed to interfere in encrypted traffic.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
8. Re:Why we cannot have nice things.. by Anonymous Coward · 2016-01-07 05:03 · Score: 0
  
  You missed the point: once the breach is discovered, the owner of the site should have the ability to revoke the bad certificate. That could be accomplished with the same challenges required by the ACME protocol for the certificate request procedure. I have not read the entire RFC, but I don't think that's currently the case. You have a `revoke-cert` endpoint that must be called with the same signing key used for the request... and that's the key that the legitimate server owner does not posses.
9. Re:Why we cannot have nice things.. by chefmonkey · 2016-01-07 07:13 · Score: 2
  
  To be approved for inclusion in pretty much any reputable application, a CA has to conform to the requirements laid out by the CA/Browser forum; see https://cabforum.org/wp-conten... -- you'll note that Section 9.6.3, bullet 5 requires the ability for the domain holder to request revocation. Let's Encrypt conforms to these requirements. While ACME requires specific authentication material to perform automatic revocation, there's a manual process in place.
  From https://letsencrypt.org/reposi... : "To report private key compromise, certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to certificates, please email cert-prob-reports@letsencrypt.org."
  Basically, all LE's policy says is "We're not going to make a unilateral decision about whether the content someone is hosting on their own domain is legitimate, for that way lies madness. If a domain owner needs a cert revoked, and they can't use the automated tools to revoke it, they need to send an email, and we'll take care of it as soon as we can verify that they're the rightful owner of the domain."
  I'm not sure it gets much more reasonable than that.
Java JRE has had a cert for years by michaelcole · 2016-01-07 03:04 · Score: 1

The Java browser plugin infected millions, loaded bloatware, and generally has been a nuisance for years.
It eventually was blacklisted from browsers.
Let's not pretend SSL certs were supposed to do things they're not. You can be certain no one is imitating the malware site. And that's all a SSL cert means.
1. Re:Java JRE has had a cert for years by Anonymous Coward · 2016-01-07 03:16 · Score: 0
  
  It does hinder automated analysis by network security products. Unless the product is using MITM, which has all it's own problems.
Malvertising is a trivially solvable problem by Anonymous Coward · 2016-01-07 03:07 · Score: 2, Insightful

Why the hell do ads need to be able to run arbitrary 3rd party scripts? Give them an image, some text, etc. and they stick it in their ad format. There's no reason to let random people on the internet inject scripts from totallynotmalwarenoreally.ru into ads on the New York Times' site.
1. Re:Malvertising is a trivially solvable problem by Anonymous Coward · 2016-01-07 03:46 · Score: 0
  
  Why the hell do ads need to be able to run arbitrary 3rd party scripts? Give them an image, some text, etc. and they stick it in their ad format. There's no reason to let random people on the internet inject scripts from totallynotmalwarenoreally.ru into ads on the New York Times' site.
  Because the New York Times is run by lazy morons. They wouldn't run ads in the print edition of their newspaper that are obviously fraudulent. But for some reason, the interwebs is somehow different. They get their ads from an ad network, who gets ads from various brokers, who get their ads from . . . god knows where.
  That's why i can go to a website that is hosting pirated software and movies and find ads for mainstream products, such as Progressive Insurance, Ford automobiles and Tide detergent.
Let's Encrypt is only for encryption by Kid+CUDA · 2016-01-07 03:15 · Score: 2, Informative

I don't see why this is news at all. Let's Encrypt is a great way to allow any webmaster to offer a TLS-protected connection between his users and his server.

As a user, seeing a website using a Let's Encrypt or StartSSL certificate does not tell me anything about the legitimacy of that website. All it does is guarantee that my connection won't be intercepted through a MITM attack. Personally, I never "just trust" the little lock icon in my address bar: I click it and see who signed it. Then I make a decision on whether or not I trust that website with my information.
1. Re:Let's Encrypt is only for encryption by Anonymous Coward · 2016-01-07 03:31 · Score: 0
  
  My thoughts on either of the two are, great for development, but if you're in prod, pay the money for a cert if for no reason other than knowing that every device supports it.
2. Re:Let's Encrypt is only for encryption by QuietLagoon · 2016-01-07 03:55 · Score: 1
  
  I never "just trust" the little lock icon in my address bar: I click it and see who signed it.
  
  That's one of the reasons I use TLSA on my website. It provides another check to the validity of my cert for those people who bother to validate it via TLSA/DANE.
3. Re:Let's Encrypt is only for encryption by WhiteKnight07 · 2016-01-07 03:58 · Score: 2
  
  99.99% of internet users are not like you. They do not understand, nor do they care about, how TLS and certificate authorities work. If they see a little lock in their address bar then they are "safe" as far as they are concerned. To most people a StartSSL cert is exactly the same as an EV cert used by a banking site. The fact that one creates a green address bar or whatever and the other does not is totally lost on them and makes no difference. Granted this is a problem. But I don't think it is one that can be solved via technical means. Lets face it. Most people just don't know enough about how the internet works to be able to use it safely.
  
  --
  
  We're going to make information free Mr. Anderson, whether you like it, or not.
4. Re:Let's Encrypt is only for encryption by TCM · 2016-01-07 04:31 · Score: 1
  
  FUD.
  Free certs technically are exactly the same as every other cert. What you probably mean is to choose a higher validation than DV. That's the only reason you should pay someone money. But that has nothing to do with which devices accept your cert. That is a matter of server config and how you configure your TLS algorithms.
  
  --
  Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
5. Re:Let's Encrypt is only for encryption by Anonymous Coward · 2016-01-07 05:48 · Score: 0
  
  But those 99.99% can be expected to learn:
  Green bar is safe, the rest is not.
  Come on that is fairly simple and non technical. If they can not tell the difference between the green bar and the lock, then I am very much certain they can not tell the difference between no lock and lock either.
6. Re:Let's Encrypt is only for encryption by CimmerianX · 2016-01-07 06:10 · Score: 1
  
  99.99% is too generous a number. Stretch out those 9s a bit more
Applies to All Non-EV Certificates by EndlessNameless · 2016-01-07 03:20 · Score: 5, Informative

If they were able to create a subdomain, that means the attackers controlled all traffic to that subdomain.
Since most certificate authorities only verify via email to the domain for which the certificate is requested, the attackers would have gotten a certificate from virtually any CA.
There are additional verification steps required for EV certificates that should thwart this sort of attack, but singling out Let's Encrypt for issuing a certificate in this case is disingenuous.
The real problem lies with the DNS registrar that accepted an unauthorized subdomain registration request. (Or maybe the client's account was compromised, in which case the victim is to blame.)
Either way, the submission titles makes it seem this is a problem with Let's Encrypt when it most certainly is not.

--

---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
1. Re: Applies to All Non-EV Certificates by IBME · 2016-01-07 03:42 · Score: 1
  
  I just snapped up a yubikey 4 nano and was curious if anyone understands them or more specifically if using a yubikey will give one "bombproof" secure logins etc.? With these as they are so poorly protected here on the interwebs and dont forget to toss in the cellular carriers, which are nothing more than glorified internet servers, it seems just a matter of time until ALL your most secret passwords are compromised. Something I do not look forward to. I installed the LastPass addon because it said it was secure but then immediately noticed a check box to enable free credit monitoring. BS on that. I realize they were bought up by logmein but now I know they were more likely bought out as in compromised. Wtf does a password mgr have a fuck to do with managing much less monitoring my credit report. Something any fuckwad has always been able to do for free?
2. Re:Applies to All Non-EV Certificates by shaitand · 2016-01-07 03:46 · Score: 1
  
  There are also dramatically increased costs for EV certs and EV certs prevent anonymity.
  
  CERTs are to ensure I'm talking to the domain I believe I am and that said communication is protected from other parties. Whether or not talking to that domain in the first place is a good idea is out of scope.
3. Re:Applies to All Non-EV Certificates by Anonymous Coward · 2016-01-07 04:00 · Score: 1
  
  I don't think you understand how domains or DNS works... you don't register a sub-domain. You create a sub-domain via an NS record in DNS. That's it. No registration required.
4. Re:Applies to All Non-EV Certificates by tepples · 2016-01-07 05:15 · Score: 1
  
  Whether or not talking to that domain in the first place is a good idea is out of scope.
  Detractors of domain-validated certificates disagree with this statement on grounds that most non-technical users won't notice the typo in "BankOfArnerica.com".
5. Re:Applies to All Non-EV Certificates by Anonymous Coward · 2016-01-13 10:04 · Score: 0
  
  It's called a domain shadowing attack. It's mentioned in the article. Google it if you don't understand what is being discussed.
Agree with Lets Encrypt by shaitand · 2016-01-07 03:44 · Score: 1

CA's have no business judging the validity of content. A cert indicates no more or less than that the content came from the person you think it came from. Malware/spyware/hacking tools are subjective concepts.

Fighting hacking/spam is the duty of police enforcement according to local law not CA's and technical companies. What next, a CA base in China or Russia refusing to grant "gays" certs for their sites as immoral? There is no line, everything is over the line, a CA should exercise zero discretion with regard to content just as an ISP should not.

What needs fixed is the standard. All certficates should be "wildcard" certficates by default and cover subdomains no matter the depth. Whoever has the cert for the domain should then be able to issue subdomain certs. This is how the certs should work because it is how the dns system works. The owner of xyz.com owns bob.xyz.com maleware.florida.xyz.com etc. The only purpose for doing otherwise is so that cert vendors can charge more making you buy certs for each of your sub domains.
1. Re:Agree with Lets Encrypt by Anonymous Coward · 2016-01-07 04:14 · Score: 0
  
  It ultimately would be a lot more secure too. The current state of affairs (browser modus operandi) is any one of 1000 CA's can sign anything and are all explicitly trusted as if they are all 100% infallible.
2. Re:Agree with Lets Encrypt by Anonymous Coward · 2016-01-07 04:54 · Score: 0
  
  Close. With SAN certs you can add subdomains easily.
  Wildcard certs raise other security risks. If one of your sites (dev-test.mysite.com) has a XSS vulnerability, an attacker can spoof dns so that store.mysite.com resolves to dev-test.mysite.com's IP and use the attack to e.g. add/steal cookies from the real session. A proper separate cert would make that throw up a browser warning. A wildcard cert does not.
3. Re:Agree with Lets Encrypt by shaitand · 2016-01-07 09:17 · Score: 1
  
  "Whoever has the cert for the domain should then be able to issue subdomain certs."
  
  That is easily solved by the person who owns mysite.com creating individual certs for those sub-domains but the authority to do so should be delegated to them not require additional sips from the CA trough and really that should happen along with registration of the domain and expire along with the domain registration. Your root NS entries point from the TLD to your authoritative NS, if you control those you control the domain. I see no reason they couldn't also include a ptr with the public key for your private CA and anything signed by that CA is a trusted credential for anything.anything.anything.mysite.com. If the owner sees fit they could then sub-delegate out authority to a any subbranch such as whatever.branch.mysite.com.
There is no such standardized ad format yet by tepples · 2016-01-07 04:15 · Score: 1

Why the hell do ads need to be able to run arbitrary 3rd party scripts? Give them an image, some text, etc. and they stick it in their ad format.
Because only scripts can animate "an image" and "some text" on a <canvas> element. Ideally, the advertiser would author the animation and export a set of data that represents keyframes, and a publicly auditable script hosted by the ad network would use this data to present the animation. But to my knowledge, there is as of yet no such standardized format to represent canvas animations.
1. Re:There is no such standardized ad format yet by Anonymous Coward · 2016-01-07 04:33 · Score: 0
  
  Because only scripts can animate "an image" and "some text"
  Wrong! Good old-fashioned gifs can animate without use of a script.
2. Re:There is no such standardized ad format yet by Shadow+IT+Ninja · 2016-01-07 05:26 · Score: 1
  
  I think you and the parent post each have a point. 3rd party scripting is being badly abused on the web today and needs to be reigned in somehow. The CA system is broken, especially where revocation is concerned. DNS needs to be more secure than it is today. Browsers need to be better at showing the level of trust in a site, in particular, the case when a cert is good for privacy encryption but not so much for authentication. Error messages from deeply embedded third party sites don't make their way to the browser. These problems combine to create the malvertising climate we have now. It's true that there is a lot of interactivity people expect on web sites today which you can't get without 3rd party scripting. The thing is that the technology needs to be reimplemented in a way that doesn't open things up for abuse so much.
3. Re:There is no such standardized ad format yet by Anonymous Coward · 2016-01-07 09:27 · Score: 0
  
  I didn't even go so far as to say no scripts, I said 3rd party scripts. You can make all the stupid animated punch the duck ads you want, and give the script to the ad network to audit and host. Why does it need to be hosted on an unknown 3rd party domain, subject to being replaced at a whim with exploit code?
Changes won't fix the problem, but still good idea by Todd+Knarr · 2016-01-07 04:17 · Score: 1

Firstly, the attackers here had enough control to alter the site's DNS data. If they've got that much control, likely they also have access to the SSL private keys for the site. Even if they don't, they've enough control that they can do anything they want anyway by using subdirectories on existing servers. So, any changes Let's Encrypt might make still won't protect against this attack. SSL server certificates insure you're talking to the host you think you're talking to, they say nothing about whether that server's controlled by who you think it is or whether it's content can be trusted.
That said, Let's Encrypt should at least verify control of the domain a certificate's being requested for before issuing it. There's several options: give the user a random nonce and confirm they can add a TXT record with the nonce in it (at either the hostname requested or higher up in the hierarchy, they can then request certificates for any hostname at or below the point they could add the record at), have the user add that nonce as an HTTP header or HTML meta header on the root page of the site, send the nonce by e-mail to an administrative mailbox for the domain and require the user to enter it (showing they at least have access to an administrative e-mail account in the domain)... there's probably more options. I think it's non-controversial that being able to get a valid trusted SSL certificate for a host in someone else's domain without the participation of that someone else is a Bad Thing.
Re:Changes won't fix the problem, but still good i by guruevi · 2016-01-07 04:53 · Score: 2

They already do confirm you have control over the domain. The only difference is that it's (as good as) fully automated through the ACME protocol. You can verify it by hosting a website on that domain, you can verify it by sending an e-mail to the domain. Any other CA (even VeriSign) does the same thing unless it's StartSSL or an EV domain for which you have to actually submit paperwork that you are the business owner.

--
Custom electronics and digital signage for your business: www.evcircuits.com
Animated GIF does not compensate for motion by tepples · 2016-01-07 04:59 · Score: 1

Good old-fashioned gifs can animate without use of a script.
Each frame of an animated GIF has to include all pixels that have changed since the last frame. They can't compensate for motion, which means text fading in or sliding in from the side will bloat the file larger than a script+keyframes approach would. And with ad networks recognizing the realities of a pay-per-bit market for Internet access, advertisers will prefer a format that fits a more attractive ad into the same file size.
It's an education issue. by Anonymous+Psychopath · 2016-01-07 05:02 · Score: 1

There's a difference between privacy and trust, but browsers don't make that clear to the user in a consistent or even useful matter. That said, nothing will ever completely fix a layer 0 issue except education.

--
Eagles may soar, but weasels don't get sucked into jet engines.
Comodo Dragon warning for DV certs by tepples · 2016-01-07 05:04 · Score: 1

Devices running the Comodo Dragon browser visibly distinguish DV from OV certificates. I don't know if it still does, but it at least used to present an interstitial page for DV certificates that resembles other browsers' interstitial for an unknown CA.

It may not be safe to exchange information with this site
The security (or SSL) certificate for this website indicates that the organization operating it may not have undergone trusted third-party validation that it is a legitimate business. Although the information passed between you and this website will be encrypted, you have no assurance of who you are actually exchanging information with, and many websites connected to cyber-crimes use this type of security certificate. Prior to exchanging sensitive information including login/password, personal identity information, or financial details such as credit card numbers with any website that generates this warning, you should find some alternative method of validating this business or consider abandoning the transaction.
Re:Changes won't fix the problem, but still good i by luvirini · 2016-01-07 05:23 · Score: 1

Lets encrypt does the checks for control of domain like the other certificate authorities.
And really people should use DNS Certification Authority Authorization(RFC 6844) to only allow the certificate authorities they want to use. Though I am not sure if all certificate authorities follow it yet, but at least most do so it is risk mitigation.
NoScript, MITM of the crypto script, and Firesheep by tepples · 2016-01-07 05:29 · Score: 3, Informative
If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.
What you describe is similar to what Tloz proposes in the question "How to replace SSL/TLS?". But using client-side script to encrypt passwords has three drawbacks:
- It breaks on machines whose owners have configured them not to run JavaScript. But perhaps people who refuse to enable JavaScript can be filed with the "web sites ought to be static and apps ought to be native" extremists.
- It leaves the server hosting the script itself open to compromise by a man in the middle.
- Once the password is set, an HTTP cookie is normally set to mark subsequent HTTP requests as authenticated. But this leaves the site open to a "Firesheep"-style session cookie cloning attack.
Does an advertiser trust a publisher's stats? by tepples · 2016-01-07 06:05 · Score: 1

But for some reason, the interwebs is somehow different
It is different. On the web, unlike in print, advertisers demand accurate view counts and accurate click counts. A web publisher that hosts advertisers' ads on its own site has an incentive to fraudulently inflate these. An ad network, on the other hand, is theoretically a neutral party and competing with other ad networks to offer analytics that are no less accurate than those of other ad networks. So how likely is an advertiser to trust reach statistics provided by a publisher compared to those provided by a well-known ad network?
Neither Google, Facebook, nor Amazon is EV by tepples · 2016-01-07 06:10 · Score: 1

The certificates for www.google.com, facebook.com, and www.amazon.com aren't EV either.
In theory, certificates of full-time for-profit companies ought to be at least organization-validated. But apart from Comodo Dragon, most browsers don't do much to distinguish a domain-validated certificate from an organization-validated one.
Re:Changes won't fix the problem, but still good i by Todd+Knarr · 2016-01-07 06:14 · Score: 1

StartSSL does domain verification by sending e-mail to an administrative address (pulled from WHOIS data) (for their Class 1 certificates anyway).
If non-EV means unsafe, not much is safe by tepples · 2016-01-07 06:20 · Score: 1

Green bar is safe, the rest is not.
By that metric, Google, Facebook, Amazon, SourceForge, and GNU are unsafe because they're not EV. (I just checked.) Twitter, GitHub, Mozilla, and Outlook/Hotmail are safe though. eBay has a green bar on those few pages it does serve with HTTPS, but it's unsafe because many pages redirect from HTTPS to HTTP.
But can a site run as a hobby, as opposed to a full-time business, be made "safe"?
It's the same fallacy behind gun arguments by Anonymous Coward · 2016-01-07 06:56 · Score: 0

The problem is that a criminal set out to defraud people, and used whatever tools he could get his hands on.
Blaming the tools is not going to solve the problem of breeding people to be criminals, just like blaming the guns won't stop gun crime.
A criminal will just buy a fucking $30 certificate if they have to, so attacking free certificate providers is a red herring fallacy.
Re:Changes won't fix the problem, but still good i by guruevi · 2016-01-07 07:28 · Score: 1

The 'free' SSL certificates, yes, but I don't think you can use them for business. Their 'verified' SSL certificates require paperwork.

--
Custom electronics and digital signage for your business: www.evcircuits.com
Let's Encrypt is not at fault for issuing the cert by Anonymous Coward · 2016-01-07 09:13 · Score: 0

But this sort of thing should be expected from DV certs, especially when they're offered at no cost. A paywall wouldn't prevent this, but it would reduce incidence.
Why not just teach your people by fsckinhippies · 2016-01-07 10:53 · Score: 2

Just because the bar is green does not mean it is safe. Everyone wanted to run from self-singed certificates because it prompted the user with a warning. You know what? That weird ass name on the cert also helps verify where it comes from. Instead we replaced certificates and trained people to look for a lock that was already easy to spoof.
Half-donkeyed auditing by tepples · 2016-01-07 11:22 · Score: 1

I didn't even go so far as to say no scripts, I said 3rd party scripts.
I misunderstood your post. Others have used the term "third-party scripts" to include any script not on the same domain as the page itself, such as the script for serving ads itself.

You can make all the stupid animated punch the duck ads you want, and give the script to the ad network to audit and host.
A third-party script hosted by the ad network is unlikely to get audited well unless it's used by a substantial number of different advertisers. That's what I meant by a "standardized format to represent canvas animations": an ad network could afford to put effort into auditing a script that plays such a format.

Why does it need to be hosted on an unknown 3rd party domain, subject to being replaced at a whim with exploit code?
The exploit code is actually an obfuscated part of the original ad itself, hosted by the ad network, because the ad network did a half-donkeyed job of auditing it.
You're just now figuring out SSL/TLS has problems? by Anonymous Coward · 2016-01-07 12:03 · Score: 0

This headline is as pointless as saying "Burglar walked into unlocked home who used a deadbolt."
DNS by Stephen+Chadfield · 2016-01-07 12:49 · Score: 3, Insightful

This is just ridiculous. The problem here is that the attacker was able to create a new DNS sub-domain. The Let's Encrypt angle is just a red herring from a company (Trend Micro) that wants to make money selling SSL certificates.
Simple solution by DewDude · 2016-01-08 03:23 · Score: 1

If your company offers free/cheap certs that he hackers are using; then we blacklist those providers. It's not fair to them; but it's not fair to us to have to worry about this crap either. It's why I run ad-blocking; not because I hate ads; but most drive-by infections come from ad networks that don't care enough to not sell malicious ad space. I'm not infecting my computer because some web developer needs to make a little money. If you have zero integrity; then you get zero respect. I'm already starting to reject certs from free/lo-cost certification issuers; the same way I reject ads from ad-networks.