Slashdot Mirror
Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites (bleepingcomputer.com)
BleepingComputer reports:
During the past year, Let's Encrypt has issued a total of 15,270 SSL certificates that contained the word 'PayPal' in the domain name or the certificate identity. Of these, approximately 14,766 (96.7%) were issued for domains that hosted phishing sites, according to an analysis carried out on a small sample of 1,000 domains, by Vincent Lynch, encryption expert for The SSL Store... Lynch, who points out the abuse of Let's Encrypt's infrastructure, doesn't blame the Certificate Authority (CA), but nevertheless, points out that other CAs have issued a combined number of 461 SSL certificates containing the term "PayPal" in the certificate information, which were later used for phishing attacks... Phishers don't target these CAs because they're commercial services, but also because they know these organizations will refuse to issue certificates for certain hot terms, like "PayPal," for example. Back in 2015, Let's Encrypt made it clear in a blog post it doesn't intend to become the Internet's HTTPS watchdog.
Of course, some web browsers don't even check whether a certificate has been revoked. An anonymous reader writes: Browser makers are also to blame, along with "security experts" who tell people HTTPS is "secure," when they should point out HTTPS means "encrypted communication channel," and not necessarily that the destination website is secure.
Of course, some web browsers don't even check whether a certificate has been revoked. An anonymous reader writes: Browser makers are also to blame, along with "security experts" who tell people HTTPS is "secure," when they should point out HTTPS means "encrypted communication channel," and not necessarily that the destination website is secure.
they are changing the name to "Let's Phish"
Does anyone remember what the point of SSL was? It's just so our users don't see the non SSL warning right?
The fight against phishing and malware content is an important one, but it does not make sense for CAs to be on the front lines
but thats just it. prior to you, people had a barrier to entry. phishing sites needed to pay money to play in the https realm or hire someone smart enough to exploit an https protected site. your service removed both of those barriers and now allows dangerous sites to quickly and easily bypass an entire host of browser security checks designed to prevent people from entering bank card information and personal data into an unprotected site. That "lock" icon in the address bar is generally enough to convince people that what theyre doing with their Visa is sane. now, with letsencrypt, its not so certain.
.info and .biz of the internet.
if you're not going to at least police fraud or abuse, youre opening the service up to become a haven for quick and easy phishing sites. if you ignore this now, you might as well pack up and leave. Chrome and Firefox will not hesitate to lower their trust in your service if it turns into the
Good people go to bed earlier.
It's to make development a pain in the balls because you're working on shit that's configured by domain name, and thus have to go hunt down every reference to foo.com and replace it with suckonmygiantfuckingcockyougooglefaggots.biz so Chrome will open your local fucking dev instance.
Once again people are confusing securing a communication with identity verification. Phishing sites can and already do buy HTTPS certs.
You know how browsers harassed self-signed certificates in the worst possible manner for ages until finally Let's Encrypt surfaced and made it possible for people who didn't want to pay the extortion fee to a commercial entity and fiddle around manually to actually get to run a HTTPS site without having instructions for each visitor on how to make an exception in their browser (which no user ever did in the history of mankind)?
Well, Let's Encrypt certificates are now going to be treated like self-signed certificates. Don't believe me? Just wait and see. All major browsers are being run by insane and/or evil people. It's going to happen.
It's time the browsers to blacklist certificates issued from Let's Encrypt. If ISPs or email service providers have a responsibility to make sure that bad guys don't use their domains for spam, phishing, downloading malware, and other nasty stuff, then so does LE. If you don't police your service, then the rest of the internet will do it for you by blocking you.
How on Earth would a non IT person "verify the legitimacy of emails and websites?"
Let's say, you entered paypal in Google and miraculously the second link leads to paypall.com (such a SEO "optimization" is entirely possible if your have enough resources) which is the exact same copy of paypal.com, which siphons your log in credentials. How would you know paypall.com is not PayPal? Extended validation is still better than nothing.
HTTPS was a badly realized afterthought and it bites people all the time. I wonder if this problem can be solved at all. There are way too many things you have to blindly trust when you're using the Internet: several layers of routing, DNS, SSL, etc. etc. etc. 99% of people in the world have no idea how this all works and how you can be sure you're safe. Then even your OS is not exactly without bugs and security vulnerabilities which allow the attacker to hijack your connection. Then you have various three/four letter agencies around the world who have ways of getting into your computer systems without you knowing.
"Verify", my arse.
This story shows the fundamental flaw of the TLS CA infrastructure: it only certifies that the connection is established with the reported DNS domain name. That is not utterly useless, but not far from it.
The protection against man-in-the-middle attack is relevant only in a handful of cases. With home Internet access, MitM can more or less only be performed by network operators, who have a lot to lose if they are caught playing these games. It is more of an issue with public access, but still rather minor.
What would be really useful would be CA that certify the honesty of the sites. “If you see our green padlock, that means this site is reliable. If they scam you, we will refund you.”
I will not hold my breath.
I'm sure the "so called" security experts you deride would point out that the S in HTTPS is not simply encryption spelled in a funny way. Security != Encryption and the role of the certificate is Authentication not Encryption. If it doesn't authenticate anything then it is worthless, and the whole bloody point of a public CA IS to be the internet's watchdog or there is no point in trusting them.
Or do they feel that the only role of an adult is to buy liquor for children ?
Nullius in verba
This message brought to you by the people that want to make you pay them for a cert.
--- How on Earth would a non IT person "verify the legitimacy of emails and websites?" ---
How about READ THE FUCKING ADDRESS BAR. Seriously, the site you are visiting is right there at the top of the page. Read It.
NoScript. You enable javascript for paypal.com and then anytime you visit paypall.com, your browser sits there not running any javascript.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
You have so much knowledge and such good people skills, I suggest you help senior citizens become more net savvy by volunteering some of your time in a nursing home or local senior citizen's center. Hopefully you can educate people like my mother, who just shook her head and said "I don't understand the instructions, it's all in geek".
How would you know paypall.com is not PayPal?
There's an extra 'l' in the domain name.
In addition, your javascript whitelist won't allow it to run anything, so it would not function like the real paypal site.
some web browsers don't even check whether a certificate has been revoked.
This is a sloppy and invalid slur, hiding behind vagueness (it's a bogus criticism of Chrome). Revocation is useless when you fully work the threat model, and similar designs to address the uselessness are probably not workable. Remember, unless a scheme can handle revoking ~every certificate at once, it's inadequate recovery for Heartbleed. It's also a privacy problem because it lets CAs build a log of all web traffic.
The best incremental refinement is short-lived certificates auto-issued by intermediate CAs. CRLSet can revoke intermediate CAs. For normal certs, don't reissue and let them expire. That's basically what lets encrypt is, except "short-lived" is not short enough, like a day or two, yet. Also, as they point out, "weakest link": it's not a real answer unless every CA does it because an undeserving attacker could get someone to sign a long-lived cert for your domain even if you use short-lived ones. But this is the bog-obvious PKI refinement that's currently fashionable. The two-tier system keeps the CRL small, and the certs subject to "confirmation" (by not appearing in the latest short-lived CRL) can be backed by HSM that can't sign things quickly but is very unlikely to sign things wrongly.
The refinement being pushed instead of the obvious one is "OSCP stapling" and perhaps "must-staple", because this preserves the CA cartel. Without some long-lived rare magical token to give you, it's difficult to convince you that you owe them lots of money, so we still give you the token as a pacifier but then implement the above sane scheme in rube goldberg fashion, moving what should be the cert into the stapled confirmation.
However I think the correct response is not the obvious refinement. It's a major rethinking of the architecture, like Sovereign Keys. In this scheme, you must give up privacy to some central server because you must do lookups on a structure too big to store locally, but you can choose to whom you give it up because the structure is a blockchain that anyone can sync. Actually it might be small enough to store on a single computer so no big deal, but even if it weren't it's still less bad than OSCP privacy because of the option of picking a mirror you "trust".
And? You may also get a wildcard certificate from whoever (even net sol) for *.mydom.com then create a host 'paypal.mydom.com' in DNS having paypal in the name, and covered by the certificate. If this article tries to discredit Let's Encrypt because they're free, paypal in the name is not the right argument.
Slashdot, fix the reply notifications... You won't get away with it...
Something about road to hell being paved with good intentions.
The issue is not SSL, certs or lack thereof. The issue is the fact that among human population there exist several fairly consistent groups. One of these groups is "low information people" (not to call them "stupid"). Another group is "dishonest people". Yet another is "well intentioned people" who want to protect the former from the latter. But, as the "wily" are, by definition, loath to play by the rules and, in general, fairly smart - they will surely find ways to exploit whatever well intentioned thing to take advantage of the "low informed".
There isn't really any solution here.
Or AutoFill. You enable AutoFill for PayPal.com, and then when your password doesn't automatically show up, you look at the URL more carefully and immediately see why.
The real threats to security are not the CAs that issue certs for sites containing PayPal in the name. The real threats are clueless sysadmins at (mostly banking) websites that insist on not allowing AutoFill and/or break their websites in ways that make AutoFill stop working when it worked before. Besides playing right into the hands of keyloggers, such actions force people to remain willing to type passwords when in reality, users should never, ever, ever type a password into a website. Ever. Seriously.
... that and browser makers, who haven't bothered to come up with a global standard for changing passwords so that users whose computers become compromised can easily reset all their passwords automatically with a single click, and also haven't bothered to come up with completely automatic plug-in update systems, thus making it easy to trick people into believing that their Flash Player or Silverlight plug-in is out of date, thus causing them to download and run a trojan horse installer that steals their password database, etc.
Check out my sci-fi/humor trilogy at PatriotsBooks.
HTTPS depends on trusting 3 things.
a) The site
b) The CA
c) The DNS
If any 1 of these things isn't trustworthy, none of them are.
Phishing site - never trustworthy.
CA - Symantec is an example, but there are lots of untrustworthy CAs https://arstechnica.com/securi...
DNS - hijacking DNS is a real thing. How much do you trust your network provider NOT to intercept all DNS and redirect them elsewhere?
(... because I'm sure they read /. and value my opinion... )
1. NEVER hide ANY part of the URL. If the URL extends beyond the size of the location box, give a nice big '...' for people to click on to see it.
2. ALWAYS show a status bar that ALWAYS shows what URL I'll go to if I click a link. NEVER allow ANYTHING to change this behavior.
3. NEVER hide the protocol.
4. Don't allow 'data' URIs in the URL bar by default. https://www.wordfence.com/blog... (This also relates to #1)
5. Don't make SUCH a big damn deal about 'https' -- big green text, giant padlock icons, etc. I've been telling people for YEARS that an HTTPS connection to bankofamurica.ru is worth NOTHING.
This won't solve everything, but the least that browser makers can do is give people the tools they need to help them make good decisions. Long story short, QUIT HIDING SHIT!
6. Bonus: enough with all these new shit TLDs. Is a world where http://blog.google/ exists (note: it does) REALLY a better place than one where it doesn't? Or is it just more confusing?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Something doesn't add-up:
During the past year, Let's Encrypt has issued a total of 15,270 SSL certificates that contained the word "PayPal" in the domain name or the certificate identity.
(Emphasis mine).
But according to Let's Encrypt, their certificates don't say anything about identity:
Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain – it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety.
Can someone explain what the author meant by the term "certificate identity" in a Domain Validation certificate? It almost seems like the author of the article is conflating the concepts of DV certificates and EV certificates into one. Or am I wrong, and DV certs do indeed have an identity?
In researching this a bit, the CA security council as well as some certificate authorities are pushing browser manufacturers to treat DV certificates differently from EV certificates, where the site owner's identity is verified. This would make sense. There's some politics going on here at Mozilla: according to Wikipedia, Firefox used to treat DV certificates subtly differently from EV certificates, but they changed that once they launched Let's Encrypt.
A person who knows to install a NoScript plugin, also knows not to blindly use google search as an address bar.
- Don't do what I do, it's probably not healthy nor safe. -
Normal people have no idea what https://paypal.com/ is. For them https://paypal.co/ looks perfectly fine (PayPal might have bought all second level domains but I highly doubt that). Normal people have no idea what "com" means, what domains levels are, what's the meaning of dot in the domain name. What's the meaning of HTTP or HTTPS whereas the former is now hidden by all major web browsers. I'm an IT pro and I've no idea why there are these three letters "://" after the protocol name. Why not "::" or "->" or any other arbitrary combination?
Normal people may want to visit paypal for the first time ever which means no AutoFill data or any indication they've arrived at the website they can really trust.
Idiots who say you should trust a website based on its name think too much of people. The Internet was designed for geeks and remains so, no matter what geeks say. And it wasn't designed with security/privacy/encryption/simplicity in mind - to the contrary, the first major protocols had nothing to do with encryption or remote party identification.
Here's an example from real life: my ISP transparently replaces IP records for DNS queries for forbidden websites (it's a usual practice even in the USA) - how on Earth you could trust a domain name, when your ISP can reroute your traffic at will? And no! I'm not using my ISP's DNS resolver - I have a recursive DNS server on my PC - which means they transparently replace my UDP traffic. The only way to be sure that my connection attempt is not spoofed is what? VPN? No, you cannot trust it either. DNSSEC hasn't really taken off and then you cannot really trust CAs nowadays.
Sorry, I've never seen so many idiots at /. simultaneously.
The person you're replying to is being needlessly abrasive, but his/her point is not entirely without merit.
The end user has some responsibilities when giving the computer instructions. One of those is to be accurate: the computer does what it is told to do, as it should. It is not in the business of being your nanny, it's in the business of providing information processing services to you. If you require assistance using it, as some people do, then that is best handled by a different mechanism. That is not the computer's responsibility.
In the end, trying to protect people from their own mistakes is a battle that cannot be won and in fact harms that cause more than it helps. The more people feel they can operate in an understanding-free manner, the more they will not bother to understand what they are doing, so it will be even easier to fool them. Dumbing down the whole infrastructure is not the path to success, it's the path to even worse problems.
Normal people have no idea what "com" means, what domains levels are, what's the meaning of dot in the domain name. What's the meaning of HTTP or HTTPS
That is a problem, but one that should be addressed by education, not by dumbing down the population even more, because that makes the majority of people even more helpless.
People are self empowered by knowledge and understanding, not by ignorance.
How is this an abuse of Let's Encrypt? Would you prefer that victims give their private information to phishing sites over plaintext? Seatbelts can be worn by bank robbery getaway drivers. Does that mean that seatbelts are a problem? The premise is absurd.
I quite agree with that, however just like I said, the Internet and computer devices are inherently insecure. How would you teach them not to trust DNS or their Internet connection? How would you teach them not to trust their OS or their computing device (now that we know that BIOS/UEFI/your NIC/HDD firmware can all be p0wned)?
As of 2017 we're all fucked. Some people naÃvely believe we aren't. The ones who usually run Windows without any decent AV. At the same time 100% of modern CPUs (x86/ARM) are rigged for remote control without you knowing. >98% of people in the world run software/firmware/integrated circuits (read CPUs, DSPs, etc. etc. etc) which only select people in the world can access and verify.
where i agree with you many just want it to work no fuss and effortlessly. and many os's and software are trying to cater to that.
Now these connections can't be man in the middle attacked. This is a (slight) improvement.
Even invalid or self signed certificates leading to encrypted but not authenticated connections are better than unencrypted and unauthenticated, though browser vendors seems to disagree.
Also, if a website is committing a crime, its far easier to attribute the attack if you have strong evidence it was conducted by the actual domain owners (or said owners were criminally negligent and let their cert get used for crime): the TLD provider should be able to identify the owner of the domain, and the cert proves it was them that did the attack.
I think end users and browser vendors need to understand the difference between trusting a connection to someone, and trusting that end point to implement what the user actually wants.
Normal people trust their search engine to return the real PayPal site when they search for it. The worst realistic scenario from a non-user getting otherwise redirected to a fake version of the site is having to contest false charges on a credit card and report the card stolen. No big deal. It becomes dangerous when you associate a bank account with it, which no mentally competent person should do when visiting a site referred from some random new website. But once you have done that, accidentally giving out your password to a phishing site becomes a really big deal, because you probably won't get that money back.
What the h*** else can you possibly use as a basis for trust? Do you expect us to create a little walled garden that prevents the free flow of information just in case some bad person decides to do something bad with that ability? We had that. It was called AOL, and it failed because it was too limited compared with the real web.
You should really be encouraging broader adoption of DNSSec so that we'll eventually be able to make DNSSec validation mandatory instead of whining on Slashdot that we aren't taking the problem seriously. Or propose a better solution. Either way.
With all due respect, has it ever occurred to you that if you think a large number of really smart people are idiots, it probably means that you don't understand the problem as much as you think you do? Just saying.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If you blame the CA, for creating valid certificate for "misleading" domain name, why do you not blame also the registar?
I think most people here would spot a fake site without the ev,
Even CA's have issued 'bad' certs to people - Symantec and others have also failed the test.
Public key infrastructure is dependent upon a system of trust. Those who issue signed certificates can either strengthen or weaken trust in the overall system. Those issuing certificates bear responsibility to maintain trust in the overall system.
well it is called "lets encrypt" which has nothing to do with "lets know who were talking to"
It's also troubling to see folks claim that the name in the address bar means anything: with UTF-8 addressing it's trivial for many sites to be spoofed by use of a similar glyph (but a very different character).
And all the while seemingly ignorant of the fact that "end-to-end" encryption often means only from your PC to the corporate firewall.
HTTPS was a badly realized afterthought and it bites people all the time. I wonder if this problem can be solved at all.
The intention of HTTPS was only to provide secure communication between the client and server.
Saying it was horribly designed afterthought because it doesn't verify the owner of the server is simply false. That was never the point. That may have been something the CAs propped up, and then browsers started blocking use of self-signed certs. So now we're back at square one, as LetsEncrypt now offers a no cost solution to replace self-signed certs.
This is what LetsEncrypt believes, as well. The entire point of LetsEncrypt is to allow everyone to securely communicate with their own sites, free from spying of ${GOVERNMENT_ENTITY} or malicious hackers.
We simply need some other way to identify if a website is who it says it is. HTTPS was never meant for that, despite what the CAs have led you to believe.
You know that there are cyrillic characters that look exactly like the roman ones we use except they have another unicode code point? So www.microsoft.com (to use a REAL example) could have a cyrillic o in there and you can't actually see the difference because the two characters are renderered identically?
Besides, I noticed that ld ' uo p uplo ,no
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
If you have auto fill turned on, your browser may remember your PayPal information. A phishing site could setup in a way to steal the auto fill information without actually showing you a form. Another problem I've realized (maybe a tad off-topic) is that PayPal has allowed users to sign in with TouchID. There are parts of the world in which law enforcement can make you use your finger to unlock your phone; this also includes applications. In other words, PayPal gave law enforcement the keys to many peoples financial information but told everyone it was for convenience.
Yes. I agree. Our local admin (who is a paranoiac) thinks autofill is the evilz. Autofill increases security for exactly that reason.
Bonus # 2: Autofill makes you much more immune to viruses that capture keystrokes, of which there are plenty.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
It was called AOL, and it failed because it was too limited compared with the real web.
And in modern times it's called Facebook and is succeeding wildly.
Inform your mother that she's a rude, lazy ass, and to pay attention to the simple instructions otherwise she can enjoy living on the streets when all of her money is stolen. Problem solved.
The problem is very few people are aware of the correct URLs, and simply put "paypal" into google and follow the first result that comes up, or click the paypal link on ebay or that arrives in an email for example... They never directly enter https://www.paypal.com/ into their browser address bar.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Whats to stop a virus from dumping the autofill cache instead of capturing keystrokes? You've traded one problem for another.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
>We simply need some other way to identify if a website is who it says it is.
This is what DNSSEC and DANE TLSA are for.
Years ago everyone who wanted an SSL cert had to provide actual corporate documentation reviewed by actual people. Everything was essentially "EV".
Then all the CA vendors said fuck it, lets make more money on volume without doing any work and switched to automated systems.
Finally Let's encrypt came along and said double fuck it not only will we use automated systems but we'll make it FREEEEEEEEE.
The end result is a phenomena well known to the technology industry. A race to the bottom where everyone ends up screwed because there is no discipline and no market incentive to chose any path other than the one of least resistance.
We now live in a world where insecure jems like RFC6844 (DNS CAA) are necessary because CA's are too lazy even to be expected to coordinate amongst themselves.
I don't believe a world of countless dozens of overlapping planet scale trust anchors is rational to begin with. I have always advocated for any signing to leverage domain holders relationship with their registrar as a standard feature of domain ownership and get lazy third party CAs out of the equation altogether. The whole system has basically devolved into this only with much worse security/financial/effort outcomes for all concerned anyway. Way past time to force the worlds CAs out of business.
Yes originally it at least made sense if you were a bank or ecommerce site or something important you paid dearly each year for a cert and got something out of it in return. The second CA's abdicated their only value over domain registrars ... meaningfully vetting those seeking their blessings it should have been the second they ceased to exist altogether. They essentially became parasitic leaches from that point forward and the world has suffered for it as a result.
browsers started blocking use of self-signed certs
They never started doing so. They always blocked them because without a CA it couldn't validate the certificate was genuine. You either make it whitelist the certificate or install a self-signed CA that you sign your certificates with. All the browsers did was make the warning more obvious and need to make a couple of extra clicks to ignore it. They did it specifically to stop people automatically clicking OK without reading the warning, and it works very well at that.
Read: https://letsencrypt.org/2015/1...
While they do conclude that they don't see CAs role for (DV certificates) to protect against phishing... They do already lookup domain names in Google Safe Browsing API before issuing certificates.
From a puristic point of view the purpose of a certificate is to prove that you are talking to example.com, and not some other domain. Verifying that example.com is your bank and not registered by a scammer is a not the purpose of a certificate.
That said, it seems they already are looking up in Google Safe Browsing API, so at-least there is some barrier to entry. And while I agree that it's not a CAs purpose to be internet police, I do hope that we'll see more best-effort protections to stem abuse. Granted this sort of a abuse is probably better fixed at registrar level.
Before they just used http without tls.
The web is moving to be encrypted. So phishing sites are being encrypted as well. No surprise. And nothing worse than before. It's even better, because just the phisher gets your creditionals, but not the NSA, which sniffes your connection to the phishing site.
The process might in fact be to block all domain-validated (DV) certificates and allow organization-validated (OV) and Extended Validation (EV) certificates. This would parallel the policy implemented by the Comodo Dragon browser, which displays a warning for DV certificates:
[First-visit validation of a self-signed certificate is] where key fingerprints in DNS can help
Not until the root domain and major TLDs are signed with a key stronger than 1024-bit RSA. Short keys are why browsers haven't added support for DANE.
Even unauthenticated encryption is better than no encryption, because it prevents passive attacks.
It also gives the user a false sense of security that an active attack is not in progress. A self-signed certificate places the bar between "passive attack" and "active attack", but browser publishers have defined the https scheme to prefer a bar between "active attack" and "typosquatting".
The registrars are *supposed* to do visual aliasing checks when issuing internationalized domain names. If that isn't happening, the failing party is clear. It isn't as though this hasn't been a known problem for years....
Check out my sci-fi/humor trilogy at PatriotsBooks.
Let's say, you entered paypal in Google and miraculously the second link leads to paypall.com
Wait.... Google lists a Fake website as Hit #2 in a search result, and people are ragging on LetsEncrypt? Clearly, the Search Engine is to blame here.
The way you safely access PayPal is DONT SEARCH FOR IT. you type http://www.paypal.com/ into your Browser address bar, AND you check the typing carefully before pressing enter.
Also, if you typo'd the website name, your browser should show an error page. And if you've ever visited www.paypal.com it should warn you that maybe you made a typo, before proceeding to access the different site.
And that's not what HTTPS is for. As mentioned that's what the CA's provided, but it certainly was not a part of HTTPS.
As another commenter pointed out, DNSSEC and DANE will provide this functionality, instead of the CAs, in the future.
An unencypted connection is fast, cacheable, and secure enough when you're just transfering photos and cat videos.
As far as I know, my browser does cache content served over https exactly the same as served over http.
But your ISP cannot cache said content. Say you have a classroom full of children all reading the same article on Wikipedia, and it's in a remote area with the only available Internet connection being a 0.13 Mbps ISDN or satellite link. With cleartext HTTP, a Squid or Polipo proxy can pull every . But with HTTPS, the proxy has to fall back to a separate CONNECT tunnel and transfer the same article 20 times unless the proxy is configured to intercept TLS, with its own root certificate in all browsers configured to use the proxy. Failure to cache in such a situation is inefficient, slow, and possibly costly if it causes the school to exceed a monthly Internet data transfer quota. (Source)
The best incremental refinement is short-lived certificates auto-issued by intermediate CAs. [...] The refinement being pushed instead of the obvious one is "OSCP stapling"
An OCSP response is a short-term statement issued by the CA that a TLS server's certificate is still valid. It can be thought of as exactly the sort of "short-lived certificate" that you describe. Stapling allows a TLS server to cache this response and present it alongside the main certificate. If only the TLS server contacts the CA to get OCSP responses, the CA can't see clients.
Sovereign Keys
From a footnote in the proposal: "In the current draft, there are additional requirements, including that an OCSP check for the CA certificate is successful".
You realize there is a large portion of the population who believe that entering the address IN GOOGLE is doing exactly what you propose right? These are not stupid people but to them searching in Google is exactly the same as using the address bar.
You enable javascript for paypal.com and then anytime you visit paypall.com, your browser sits there not running any javascript.
Then phishers are going to make their sites compatible with NoScript, such as by computing the final DOM, serializing it to HTML, and sending that to the mark instead of the script that generates the DOM.
LetsEncrypt now offers a no cost solution to replace self-signed certs.
This is true only for servers with fully qualified domain names, not for internal servers with private IP addresses or made-up TLDs such as .local or .internal. Is every householder supposed to buy a domain to make HTTPS communication across the LAN with a router, printer, or streaming media server work?
To be fair this is because browsers like Chrome (swiftly followed by Edge and Firefox) have all decided that the search bar SHOULD act exactly like search. They removed the dedicated search box in favour of a "smart" unified typing place that in my experience, fails to select the correct thing to do about 50% of the time.
It's almost impossible to just type a hostname into the Complete Unified New Technology bar and consistently have the browser load the site (unless you hack Firefox options; I don't use Chrome so I don't know if it's possible at all and I can't see a way to make Edge be sane). No - a simple word MUST mean you're searching for something even if it's locally resolvable and not a word in any language. Thanks Google et al, making the world a worse place, one step at a time.
Why are you encrypting traffic within your own private network?
Except that they don't. Unless you can show me an example where they don't use any javascript in a login page.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
In other words, the business model of Let's Encrypt is to sell digital certificates that aren't worth the electrons they are printed on.
Let's encrypt is a free (price as-in-beer, code as-in-speech) service. They don't have a business model.
They have a purpose (the same as CACert, by the way), to issue simple certificates that can verify that "blah.com" is indeed "blah.com".
(As opposed to some man-in-the-middle attacker mascarading as "blah.com" using a different 3rd server).
They do not certify any thing else, and indeed the certificates' fields. This certificate doesn't certify any organisation name.
This is even reflected in some browser's URL bar.
e.g.: in Mozilla's Firefox.
- Go to a "let's encrypt" website (like here on /. ) or one certified by CACert :
you only get the green padlock (sign that the communication is encrypted) and no other indication.
let's encrypt only checked that slashdot.org is indeed slashdot.org, but didn't check anything regarding ownership.
(it might as well be someone trying to impersonate Slash, DJ Slash or Fat Boy Slim)
- Go to paypal :
in addition to the padlock, you get an indication that certificate is certifying that the server is owned by PayPal Inc.
(Symantec actually checked that PayPal Inc is indeed own
Issuing a certificate to BobsCarRepair.com is one thing. Obviously you have no way of knowing whether or not Bob is a reputable business.
Even further : it doesn't even certify that owner of the website is someone called bob. It only certifies you that it is indeed bobscarrepair.com
It might as well be owned by Alice, for what you know.
It only certifies that Eve isn't wiretapping you when you give your credit card number to buy parts.
However, Issuing 14,000+ certificates that contain the word PayPal, to domains not owned by the real PayPal, is incompetence on a massive scale and calls into question Let's Encrypt's honesty and trustworthiness.
Nope.
There's a difference between guaranteeing a secure channel (against 3rd party eaves dropping).
And guaranteeing identity.
is
These are 2 different concepts.
Let's encrypt only takes care of the first one and has never ever hoped to tackle the second problem. They DO NOT certify owners, this field is intently left blank on their certificates.
The point of Let's Encrypt (as its name says) is that encryption becomes the norm on the web. In order to avoid massively stupid blunders, like the dead easy identity theft demonstrated by FireSheep.
That's something that CAN BE achieved for free, on a massive scale, like Let's Encrypt and CACert are doing.
There's no realistic way that let's encrypt could in any way confirm owner identity for free on this massive scale.
That's something which is very easy to understand for people who have some basic knowledge of security.
Saddly, sheeple are stupid. So you need to educate them and try to find ways to make them understand.
(e.g.: the above mentionned "show certified owner in the URL bar if provided" that Firefox is doing).
But sapping efforts like "Let's Encrypt" which are providing very valuable service (bringing the availability of HTTPS, TLS/SSL, etc. on a massice scale), simply because some idiot can't make the difference between "protection against 3rd party eavesdrop" and "identity of the owner" is counter-productive
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
and very few people would check EV
That's why some browsers like Firefox checks it for you and display it right in the URL bar.
You can't miss it.
What you really need is the domain registrars to check that if sites are being registered that are similar to a company name or trademark that they have a legitimate right to use that name.
Hey, then you need to ban slashdot.org, because it's name is similar to Slash. Or to DJ Slash. Or to Fatboy Slim's song.
The problem with "check that if sites are being registered that are similar to a company name or trademark" is that it's a complex task require some thinking that it's not trivial to automate for absolutely free (and in a way that won't be trivially circumvented by attackers).
It goes beyond the point of Let's Encrypt (whose point is, as the name indicate, just to make encryption available).
Or build a chain-of-trust system where people can blacklist a bad domain by voting it down
Which isn't an easy task to do (how many - outside of /. - to use PGP on a regular basis ?) Chain-of-trust system aren't easy.
Blacklist aren't silver bullet neither : an attacker could still bank on a quick attack trying to scam as many users as possible before getting flagged.
(See all the "software to make a millionaire out of you on binary option sites !" scam that are popping every where. Site costs under a couple of hundred in stock-photos / fiverr actors / ads promotion to set up, and can manage to make a few thousands selling snake oil before getting reported and shut down).
Neither of them have anything to do with HTTPS.
Which brings us back to the point : Let's Encrypt's purpose, as it names implies, is to bring the S in HTTPS and nothing more.
It's not their job solving the certification of owner in an easy way.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It's not PayPal itself, but the login page for Phil's Hobby Shop can work without JavaScript. The only part that changes with script off is that you have to submit with a blank password in order to enable "Show password as I type".
Why are you encrypting traffic within your own private network?
To avoid loss of functionality once the Fullscreen API becomes limited to secure contexts. Browsers no longer support sensitive JavaScript APIs over cleartext HTTP. There are plans to make Fullscreen API unavailable over cleartext HTTP because of demonstrated phishing attacks. Without the Fullscreen API, streaming video from a home NAS will be limited to a window.
Browser makers are also to blame, along with "security experts" who tell people HTTPS is "secure," when they should point out HTTPS means "encrypted communication channel," and not necessarily that the destination website is secure.
Bullshit. The main purpose - or at least one of the main purposes - of PKI is that you're supposed to trust the certificate issuing authority to be validating the identity of the server. In practice, this becomes broken when CAs like LetsEncrypt decide that 'they don't want to be an internet watchdog' while issuing certificates that are vouching for the identity of phishing sites.
Fair enough. Luckily, phishers don't bother with a non-javascript login page even though it is possible.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
If by succeeding, you mean completely failing to have any significant role in online commerce, and not being a significant source of information beyond currently trending events, then sure. Call me when there's something equivalent to Wikipedia that's built into Facebook without linking out into the Internet as a whole, or something equivalent to Amazon, or something equivalent to airline and hotel reservation websites, or....
So no, Facebook is not succeeding as a replacement for the Internet—only for the very narrow slice of the Internet that was previously dominated by MySpace.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If by succeeding, you mean completely failing to have any significant role in online commerce, and not being a significant source of information beyond currently trending events, then sure. Call me when there's something equivalent to Wikipedia that's built into Facebook without linking out into the Internet as a whole, or something equivalent to Amazon, or something equivalent to airline and hotel reservation websites, or....
So no, Facebook is not succeeding as a replacement for the Internet—only for the very narrow slice of the Internet that was previously dominated by MySpace.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If by succeeding, you mean completely failing to have any significant role in online commerce, and not being a significant source of information beyond currently trending events, then sure. Call me when there's something equivalent to Wikipedia that's built into Facebook without linking out into the Internet as a whole, or something equivalent to Amazon, or something equivalent to airline and hotel reservation websites, or....
So no, Facebook is not succeeding as a replacement for the Internetâ"only for the very narrow slice of the Internet that was previously dominated by MySpace.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Oops. Slashdot's website broke badly. Submissions weren't showing up for minutes. And now I got three identical posts because the duplicate post detection also wasn't working. *sigh*. Sorry for the noise.
Check out my sci-fi/humor trilogy at PatriotsBooks.