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



The Bike Shed

Web Services

  Download PDF version of this article PDF

Error 526 Ray ID: 46d69e193c641888 • 2018-10-21 20:54:07 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

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.

acmqueue

Originally published in Queue vol. 13, no. 2
see this item in the ACM Digital Library


Tweet



Related:

Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - Tracking and Controlling Microservice Dependencies
Dependency management is a crucial part of system and software design.


Diptanu Gon Choudhury, Timothy Perrett - Designing Cluster Schedulers for Internet-Scale Services
Embracing failures for improving availability


Štěpán Davidovič, Betsy Beyer - Canary Analysis Service
Automated canarying quickens development, improves production safety, and helps prevent outages.


Benjamin Treynor Sloss, Mike Dahlin, Vivek Rau, Betsy Beyer - The Calculus of Service Availability
You're only as available as the sum of your dependencies.



Comments

(newest first)

Displaying 10 most recent comments. Read the full list here

Kristoffer Björk | Tue, 17 Mar 2015 09:05:39 UTC

There are also "middleboxes" that either inspects traffic or change it (ad and/or javascript injection etc). These do not support http2 yet, so without encrypting http2 you need to wait for all these boxes to update before you can test and/or deploy anything. This is why SCTP and other newer (better?) protocols arent used, a massive amount of broken devices that brakes when you do something else than really old protocols since noone bother to update the software they run.


Adam Roach | Sun, 22 Feb 2015 21:06:09 UTC

"The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost."

You can't evaluate this behavior in a vacuum, though. Using your definitions for privacy and secrecy: these kinds of decisions are coupled with very deliberate actions that provide actual privacy (which provides protection against active and passive attackers) for the same cost as one can achieve secrecy (which only protects against passive attacks). See https://letsencrypt.org/ for the alternative. All other things being equal, the tools "Let's Encrypt" will provide are even easier to use than installing a self-signed cert.

When faced with the opportunity to deploy good security for the same cost as bad, choosing the good security path seems like a far more rational choice.


Greg Wilkins | Fri, 09 Jan 2015 12:57:06 UTC

@Robert Thille, actually TLS does not well hide who is using the NYT contact form vs who is reading the NYT front page. Given just the request/response sizes and their timing and sequense, the NSA can pretty much determine what pages you are reading on the NYT, if you have navigated to the contacts page and if you are sending data.

TLS everywhere is over promising. It might help privacy a little bit in a few circumstances, but not a lot in many more.


Rich | Thu, 08 Jan 2015 20:25:39 UTC

Authenticated communications aren't just for privacy. It doesn't matter if the resource I'm downloading is a news article, source code, an executable, or even cat pictures, I want to be certain that what I'm getting is actually what I'm expecting it to be, without any alterations having been made in-transit by third parties. The same is true for the information going in the opposite direction; what I transmit ought to arrive at its destination unaltered by any third parties.

Is SSL/TLS as currently implemented, with its reliance on trusting known-untrustworthy third parties, fundamentally broken? Absolutely. Even with it as broken as it currently is, it's still better than nothing though.


Jack | Thu, 08 Jan 2015 12:37:07 UTC

"most memorable event of 1989" - WTF!? What about the Berlin wall coming down?


malthe | Thu, 08 Jan 2015 07:28:42 UTC

NYT is a large website and you can engage with it. Why would I not want encryption? Note that NYT can't see my other traffic, but those who tap in on the network can.


duane | Thu, 08 Jan 2015 04:15:25 UTC

"dub dub dub" that wasn't so hard, was it

(apparently the comment filter wasn't happy with this being a one line comment, good going boys)


Milton | Wed, 07 Jan 2015 23:15:10 UTC

www is nothing if not international, where it often has fewer sylables. But although I never spoke to a German about it, it seems absolutely hilarious in German. It is pronounced like the word "weh" (sounds like english "vay") which means woe (or injury), invoking an almost biblical "woe woe woe" at the beginning of each url, or, like the Max und Moritz classic German stories describing fairly violent strikes carried out against members the community by Max and Moritz "wehe wehe wehe wenn ich auf das ende sehe".


Robert Thille | Wed, 07 Jan 2015 20:43:22 UTC

Well, if everyone going to the NYT site use https, and almost all of them were reading news, and some of them were using a contact form to reach a reporter to reveal illegal spying by the NSA, it'd be a lot harder for the NSA to catch that than if only the contact form were over https. Whether that's worth the cost in CO2 pollution, I don't know...


rotek | Wed, 07 Jan 2015 18:09:51 UTC

Furthermore, HTTP/2.0 does not address one of the primary problems with HTTP, head of line blocking, because it is still TCP based.

HTTP 2.0 is even more vulnerable to it, because it transmits all the data on the same TCP connection. When even one packet gets lost, the whole communication with the server is blocked. Whereas, in HTTP/1.1, only one of (for example) six parallel TCP connections is blocked in such case.


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

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.