November/December 2018 issue of acmqueue The November/December issue of acmqueue is out now

Subscribers and ACM Professional members login here


  Download PDF version of this article PDF

Error 526 Ray ID: 4ab569fbbffb9218 • 2019-02-19 02:48:21 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. 12, no. 2
see this item in the ACM Digital Library



Simson Garfinkel, John M. Abowd, Christian Martindale - Understanding Database Reconstruction Attacks on Public Data
These attacks on statistical databases are no longer a theoretical danger.

Rich Bennett, Craig Callahan, Stacy Jones, Matt Levine, Merrill Miller, Andy Ozment - How to Live in a Post-Meltdown and -Spectre World
Learn from the past to prepare for the next battle.

Arvind Narayanan, Jeremy Clark - Bitcoin's Academic Pedigree
The concept of cryptocurrencies is built from forgotten ideas in research literature.

Geetanjali Sampemane - Internal Access Controls
Trust, but Verify


(newest first)

cianci | Thu, 17 Apr 2014 09:39:53 UTC

Read Network Time Foundation's response to the DRDoS attacks learn how to stop these attacks in their tracks here:

J Bohm | Sat, 12 Apr 2014 21:24:02 UTC

Two things that could be done:

1. Have upstreams and IX-es start penalizing network that let out packets that should have been stopped by SAV/egress. In other words, for every packet caught by address ingress filters at the upstream, charge the downstream an unpleasantly large fee, such as $1/packet. This will provide a financial incentive for the practice to spread downward to the lower tier ISPs and to other tier 1 entities, as each entity gets the economic choice: implement filtering and/or charge $1+profit from the next level. $1 may not seem much, until you multiply by the bandwidth of such wholesale connections (typically around a million packets/second or more), then the cost of non-compliance becomes glaringly obvious.

2. Someone like ISC should publish a reference library similar to the DNS RRL code, but disembodied from any specific protocol. Protocol implementers would simply call it with a purported source address of a packet soliciting a stateless reply, and the library would return block/don't block based on the library's internal statistical and timing logic. The library-using protocol implementation will decide which packet contents and protocol state imply an unconfirmed return address, while the library will simply look for unusually frequent addresses.

3. Finally ISP level routers could start offering ICMP amplification filters: If a source address send repeated error ICMP messages concerning specific traffic, rate limit such traffic to that source address. If the error message rate approaches the rate of actual packets going downstream, also start synthesizing identical ICMP packets for the discarded packets in order to trigger the next routers upwards. But if the ICMP error messages exceed the volume or other statistic property of the packets (such as counts of various hashes of the initial bytes) being complained against, reverse the filtering and treat the errors as an ongoing DDOS abuse of the ICMP amplifier itself. The benefit to ISPs is not transporting as many DDOS packets, leaving the bandwidth for legitimate paid traffic. Note that this logic would be semi-dumb, in that it does not need to understand the traffic, just the established ICMP error messages. The smart edge decides what traffic it wants rejected by simply doing so, and the smart edge operators can adjust the rejection based on actual traffic desires.

Tisha | Thu, 20 Feb 2014 00:35:03 UTC

If you haven't had a chance to read Network Time Foundation's response to the DRDoS attacks, take a moment to do so, and learn how to stop these attacks in their tracks here:

Tristan Slominski | Sun, 16 Feb 2014 17:17:14 UTC

SAV is not the only solution to this problem. Consider the Object Capability perspective where the destination addresses are "unguessable."

Unfortunately, we don't seem to have enough bits in our current protocols and infrastructure to provide enough address space where we can assign addresses to everything that needs them while keeping the used address space sparse enough to make them practically unguessable through random search.

David Collier-Brown | Tue, 11 Feb 2014 14:12:21 UTC

And, just to add emphasis to the article, we have a massive NTP-based DDOS running this morning: see

--dave [email protected]

Paul Vixie | Mon, 10 Feb 2014 04:26:46 UTC

Yes, it's (ultimately) self destructive to skimp on things like SAV. However, the "chemical polluter" business model is very attractive to management teams and shareholders: the profit occurs "here" whereas the damage, and the costs shifted onto the larger economy, occur "down there".

See also:

David Collier-Brown | Sun, 09 Feb 2014 00:57:47 UTC

I've had customers who bewail in turn the people providing internet services, because they won't do such end-user-protective things as source-address validation and you've-become-part-of-a-botnet detection.

I'm still a bit surprised that that's the case, and wonder why large customer ISPs like Rogers in Canada (one of our duopoly, along with Ma Bell) doesn't do SAV.

I assume they aren't in the business of renting out botnets, so I'm puzzled at them not doing basic tasks to keep their customers from being the target of botnets and DDOS attacks.

Surely it's being self-destructive of them?

--dave [email protected]

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.