July/August 2018 issue of acmqueue The July/August issue of acmqueue is out now
Subscribers and ACM Professional members login here

Web Security

  Download PDF version of this article PDF

Error 526 Ray ID: 46e0a7904a4d9200 • 2018-10-23 02:08:12 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 10, no. 11
see this item in the ACM Digital Library



Paul Vixie - Go Static or Go Home
In the end, dynamic systems are simply less secure.

Axel Arnbak, Hadi Asghari, Michel Van Eeten, Nico Van Eijk - Security Collapse in the HTTPS Market
Assessing legal and technical solutions to secure HTTPS

Sharon Goldberg - Why Is It Taking So Long to Secure Internet Routing?
Routing security incidents can still slip past deployed security defenses.

Ben Laurie - Certificate Transparency
Public, verifiable, append-only logs


(newest first)

Displaying 10 most recent comments. Read the full list here

anD | Fri, 13 Sep 2013 21:33:53 UTC

It is interesting that this page uses the following tracking cookies for Google Analytics, Google +1, and Facebook Connect.

Chris Leonard | Mon, 25 Mar 2013 18:34:57 UTC

I think that the people who say that more responsible browsing habits will fix these problems do not understand the problem. These are information-gathering techniques that happen routinely on websites you trust. It isn't just some trivial matter of using Incognito mode and then you're safe. Many of these problems cannot be prevented by users in any way without breaking web apps.

Also, to the person who said that this is just client-server computing reinvented, I see where you're coming from, but phone and Metro apps can generally behave more like browsers, with display logic on the client and (mostly) everything else on the server. Traditional client-server apps have much "fatter" clients, which leads to application maintenance difficulty compared to an iOS / Android / Metro-style app model.

The person who pointed out that Windows 8 is leaning in the right direction is spot on. Build apps on an infrastructure that enforces an appropriate degree of separation. Then say goodbye to browsers, and I say good riddance.

sudon't | Sun, 17 Mar 2013 18:26:38 UTC

I have alway felt that security is up to the individual. Otherwise, you're asking essentially dishonest people, (politicians, businesses), to protect you from themselves. But is what I do enough? My router access is https only, and password set. I create a new identity for each site, and never log in with a Google or FB identity, (thank god for Keychain!). I never use my real name online. I use AdBlock, Cookies, Ghostery, JavaScript Blocker extensions, and Privoxy. And of course, I use a Mac. I wish that I could encrypt my email, but everyone else is too lazy to do it. Still, I wonder what other holes are left unplugged.

qmc | Tue, 12 Mar 2013 02:28:47 UTC

The rfc1918 problem is not html's fault at all. The problem stems from everyone having their router on one of about 6 different GPs, because of pnat which can hardly be blamed on html. If everyone had their own networks (v4 or v6) this wouldn't be an issue. Also, it doesn't protect any users who aren't on rfc1918 space (corps or delegations). The real issue is the poorly designed embedded webservers which don't require any sort of form token to make changes.

jon | Fri, 09 Nov 2012 07:58:57 UTC

I think I'll stick with using a modest amount of intelligence while browsing the web. Has done the trick the last 15 years. Also, people should not be allowed on the internet without some sort of test. We don't let everyone drive a car too, do we?

Eric | Thu, 08 Nov 2012 15:28:17 UTC

How many of Mr. Grossman's identified vulnerabilities can be solved through the use of browser-side plugins like Ghostery or NoScript? Or are the issues so deep in browser design that isolation is the only currently practical solution, e.g the profile-per-site Firefox workaround linked to in Matthias' comment?

John B | Thu, 08 Nov 2012 13:04:50 UTC

I rather think the presenter is being a wee bit facetious regarding iOS or Android "separating" apps. Both platforms' apps act rather incestuously and are designed intentionally to interoperate at levels invisible to the user, without the user's awareness or consent.

Fred Andrews | Thu, 08 Nov 2012 01:56:53 UTC

Thank you for the great explanation of the issues. The W3C Private User Agent Community Group, http://www.w3.org/community/pua/, is exploring some of these issues and has some options that you may be interested in, see: http://www.w3.org/community/pua/wiki/Draft

cheers Fred

Karlan | Wed, 07 Nov 2012 23:08:12 UTC

There are any number of plugins and options within most browsers that are able to address address a number of these issues.

Regardless of the security implications, though, why is the solution to build a more restrictive system to provide safeguards, rather than trying to improve education and awareness about the risks and insecurities that are inherent to the existing system? The former provides no incentive for critical thought and requires the expenditure of rather significant amounts of effort by the people least likely to be personally effected by these flaws at the cost of elevated restrictions built into the system, whereas the latter provides an incentive for elevated levels of critical thought and increased effort by the people most likely to be effected by these issues at a cost of the continuation of the current systemic state of affairs.

The general public may not like being told that their browsing methods are wrong, but as indicated in the first comment, all of the attack methods identified in the article can be addressed by browsing in an "old-fashioned" manner, without being logged into the browser, visiting only one page at a time, and having the browser clear your cache and cookies at the end of each session. This method need only be pursued for access to sites for which the user wants to ensure a secure browsing session.

Frankly, since IP addresses are available by necessity to web administrators, and IP Address Geo-location is in many cases more accurate than "City/State", going down to the street address level, the ability to unmask most users will still be available to those dedicated and malicious admins, by virtue of pulling the IP Address geo-location, going to that place, and checking through the user's mail, peering in through the user's window, or checking out the contents of the user's car. This will also reveal, for many users, their banking choices, credit card selections, and shopping tendencies. The user must take steps to be aware of and safeguard against these physical intrusions, why should digital intrusions require developer-side intervention to solve?

Christine | Wed, 07 Nov 2012 22:17:36 UTC

Err, desktop apps, isn't that what we were doing about 20 years ago, before everyone said we should move to web sites? Does "client-server" ring a bell?

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.