September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



The Bike Shed

Security

  Download PDF version of this article PDF

Error 526 Ray ID: 47cc974d6a3e218c • 2018-11-20 17:21:06 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. 12, no. 3
see this item in the ACM Digital Library


Tweet


Related:

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


Thomas Wadlow - Who Must You Trust?
You must have some trust if you want to get anything done.



Comments

(newest first)

Displaying 10 most recent comments. Read the full list here

Keith | Tue, 27 Oct 2015 05:13:20 UTC

It is refreshing to see that a reputable software engineer has openly criticized OpenSSL. OpenSSL is a terrible piece of software. I started using it in 2001.

The API makes no sense at all. The functions that you call, the way they're called and the sequence the functions are called in cannot be determined from reading the documentation. You have to rely on examples and look at the source code of accompanying programs.

Function names are made up from macros. This means you cannot easily find them in the source code. These names can change from one release to the next.

Upgrading to a newer version of OpenSSL will almost always break application code that uses the API. I have concluded that only the authors of OpenSSL can know how to use it. The only portable and reliable way to use OpenSSL is to call the application program with the appropriate command line arguments.


Alex | Wed, 06 Aug 2014 02:44:12 UTC

Question:

1. What is the difference between the heartbleed bug and other major problems/bugs with openssl and those of proprietary SSL implementations?

If you flip to the back of the book, you'll find answers to all odd numbered questions:

1. The bug was found, reported, and corrected.

I find it humorous things like this are highlighted when these problems exist in ALL software, not just open source software, and certainly not just openssl. When is the last time any proprietary SSL implementation was audited by a third party? If never is your guess, you're probably right. What makes you think any of their code is any better? Do you just trust their code is more secure? I don't -- I'm only a weekend hacker (and I wouldn't even call myself that level) and I wouldn't say that ~50% of the professional devs I meet are some combination under-educated, under-skilled, and extremely lacking in critical thinking/problem solving skills, and there are a lot of people in the industry who would agree with me. Surely some of those people must be working on SSL implementations, or other security-centric software.


Dan Cross | Fri, 09 May 2014 16:27:23 UTC

tal: it evaluates to neither. :-) It's 2^17 (arithmetic shift has lower precedence than addition).

Something I learned long ago is that if one is to successfully program in some language, one must write idiomatic code in that language. Unfortunately, I think that one of the problems with writing C code is that there is a lack of idiom around things like parenthesizing expressions that can lead to surprising problems if one is not familiar with the precedence rules of the language.


Martin Leiser | Fri, 25 Apr 2014 21:19:11 UTC

hmmm... I think it is all about Architecture. Software has bug. Period. On the other side: We know for 50 years how a MMU works. Hardware has bugs too, but much less. Why is to web server, openssl, the private key in one adress space? Use stunnel with PKCS11 to off load the private key. And the web server in a different process.

Two simpl rules: Divide and conquer. Least privilege.

Add a third rule: CPUs are cheap.. switch off optimizations for security relevant code.

But all that is not the trend of today is multithreading, throwing 100.000.000 Lines of code in one application server.....

Dont blame the openssl programmers, it is their bug, but our fault.


Sebastiaan | Thu, 17 Apr 2014 22:45:53 UTC

Must be because English is not my native language, but in my book these commits don't fall in the category 'typo'...

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=79dabcc1373be17283d736901ddf9194609ba701

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=82f42a1d2e9271359b60d16249c26baadae788db

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=24f599af21dfd8e1de693fd84fb612269c28de0c


Sebastiaan | Thu, 17 Apr 2014 22:21:07 UTC

@willy just picked two random commits and yup, it's scary!

A new go to fail in the making? I'm no C programmer, but these two commits removed curly brackets and subsequently converted a single line of code inside an 'if' statement to two lines... Sure this code is correct, but *visually* harder a lot harder to spot?

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=34e43b909f02de444678d937ed3dc347ce13ba1a

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=833a896681b3287e5ab9c01f4f0234691f4076a8


Morten Jensen | Wed, 16 Apr 2014 20:37:41 UTC

Great article, was referred here from the version2.dk debate: http://www.version2.dk/blog/det-skandaleramte-sikkerhedslag-og-hvad-goer-vi-nu-57357

> /* > * The aim of right-shifting md_size is so that the compiler > * doesn't figure out that it can remove div_spoiler as that > * would require it to prove that md_size is always even, > * which I hope is beyond it. > */ > div_spoiler = md_size >> 1; > div_spoiler rotate_offset = > (div_spoiler + mac_start - scan_start) % md_size; > > Be honest  would you have considered a proven, correct, compiler improvement a security risk > before I showed you that? > > Of course you wouldn't! It was proven correct, wasn't it?

I do embedded development, and I sometimes experience that I have to qualify a variable volatile, to get the compiler to stop optimizing the code in ways that spoils the intended behavior. I would imagine the OpenSSL code could do the operation on a volatile-qualified variable and achieve the same effect without having to resort to nasty tricks ? From my K&R on the volatile qualifier: "The purpose of volatile is to force an implementation to suppress optimization that could otherwise occur."


Peter Kriens | Wed, 16 Apr 2014 14:39:18 UTC

Isn't this also a reason to not program this kind of code in C(++) instead of a managed language?


Kevin L | Wed, 16 Apr 2014 11:32:12 UTC

As an experienced engineer in both the process industries (MS in ChemE) and software (BS in CompSci), I think that data breaches at the SSL/TLS layer need to be treated in much the same way as pressure breaches in physical systems: you use multiple independent systems to verify each other **while online**, and if any one of those systems sees a problem you interrupt the flow (terminate the connection).

Applied to this case, that would be two or more SSL libraries executing in separate processes that would each perform the SSL/TLS protocol independently, with the HTTP process comparing their outputs and only sending bytes to the other side when the outputs fully agree. If they disagree, the HTTP daemon would log an error and terminate the connection. In this fashion each library would expose the bugs in the other, while protecting the users. Eventually both libraries would get better, only failing simultaneously for errors in the protocol design or the underlying crypto math. (This is also the approach used in aviation: 3 computers, 2 to check for hardware faults and a third in an independent implementation to check for logic faults.)

Outside of generating nonces and random numbers that would have to be passed between the libraries and the HTTP process, this doesn't seem like it would be too hard to do.


Javier | Wed, 16 Apr 2014 04:01:52 UTC

Very nice article

Aside from DANE, Convergence(http://convergence.io) is another alternative to CA. OpenBSD is cleaning OpenSSL(http://undeadly.org/cgi?action=article&sid=20140415093252)


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

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.