KeyChest blog
KeyChest updates, information, and write-ups

How Let's Encrypt Works

There is relatively little information about how Let's Encrypt actually works. Read on how is your HTTPS certificate created and how the magic works.

<p>You may well know that Let's Encrypt is a not-for-profit organization that provides SSL certificates for free. You may also know there is a huge number of "clients" - small software packages that you need to install on your server to start using Let's Encrypt. There is relatively little information about how it actually works.</p><hr><p>I think it's important to bear in mind that Let's Encrypt is funded and managed by <span style="background-color: rgb(253, 253, 253); color: rgb(0, 0, 0);">&nbsp;</span><a href="https://www.abetterinternet.org/" target="_blank" style="background-color: rgb(253, 253, 253); color: rgb(23, 86, 169);">Internet Security Research Group (ISRG), aka "abetterinternet.com</a><span style="background-color: rgb(253, 253, 253); color: rgb(23, 86, 169);"> </span><span style="background-color: rgb(253, 253, 253); color: rgb(0, 0, 0);">. Its funding comes from many sponsors but </span>&nbsp;<a href="https://www.abetterinternet.org/documents/2019-ISRG-Annual-Report-Mobile.pdf" target="_blank">40% is provided by "platinum" and "gold" level</a> (Mozilla, CISCO, OVHcloud, EFF, Chrome, Facebook, and Internet Society, IdenTrust, and Ford Foundation).</p><p>The Let's Encrypt's initial goal was to automate SSL management and provide it for free as a vehicle to push for 100% web encryption. I believe that the availability of free certificates was a significant aspect when Google, Apple, Microsoft, ... started discouraging users from visiting insecure web sites (i.e., web sites without HTTPS). </p><p>Let's Encrypt does a great job when you have a few websites or a couple of administrators who can build in-house tools to ensure that all is running smoothly and resolve failures. I have summarised some of the <a href="https://keychest.net/stories/what-are-disadvantages-of-lets-encrypt" target="_blank">issues to consider before you start using Let's Encrypt in a previous blog post</a>.</p><h2>Let's Encrypt and Automation</h2><p>Let's Encrypt has developed its standard defining the API and operational concepts. They called it Automatic Certificate Management Environment (ACME). They built the certificate authority using the initial version but they also created a working group to develop an open standard. This has been <a href="https://tools.ietf.org/html/rfc8555" target="_blank">finalized</a> (currently RFC-8555 in the "proposed standard" state) in March 2019. Because it has introduced some breaking changes, Let's Encrypt started calling it ACMEv2, possibly because they implemented a new API compliant with the RFC-8555 standard and named it "acme-v02". Although it's simply "ACME" for the rest of the world.</p><p>The automation is based on a RESTful API that requires users to create an account identified by a public key. This key is then used to protect all messages sent from clients to an ACME server (= Let's Encrypt).</p><p>The protocol is defined around the following terms:</p><ul><li>account - an asymmetric key that identifies a client. It is also used to enforce some of the limits on the API usage, so-called "rate limits". Some of the rate limits are also measured per registered domain or the IP address of the client.</li><li>order - this is an actual request for a new certificate.</li><li>authorization / authz - it's an object with the validation status of an order. Each order has one validation object.</li><li>challenge - the challenge is an object that defines a method and parameters to complete authorizations. Each validation has several challenges - one for each validation method (Let's Encrypt offers HTTP, DNS, and TLS-ALPN).</li><li>certificate - it's an "address" from which you can eventually download a new certificate. This address is pretty much permanent.</li></ul><h2>Protocol</h2><p>The picture below shows the three basic steps of the ACME protocol. A client (e.g., acme.sh, certbot) will initiate a certificate request and obtain back authentication data – step 1. </p><p>This authentication is absolutely crucial as it ensures that only you can request certificates for your servers. In other words, via the authentication, you prove the control over your internet domain name and servers. You can prove this control either by adding the authorization data to your web server (so it can be accessed with the HTTP protocol by the Let's Encrypt service) or by adding the authorization data to your DNS records.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="ACME Issuance Protocol" src="/storage/storage/wink/images/RgwMc3yKEwEx8qcPvcDxXPkbVIeJUwDiRmzChRXJ.png"><p>ACME Issuance Protocol</p></div><p>Step 2 is the actual validation of your domain control. It is also the most difficult step as you need to integrate the certificate renewal with either your web server or your DNS management.</p><p><em>Note: I’m sure you noticed that in the diagram, the data for Step 2 magically appear where it is expected. As no magic, it has to be a sophisticated technology.</em></p><p>Let’s Encrypt will try to collect the authorization data it provides in step 1 using one of the available methods. Once the authorization is completed, Letsencrypt will&nbsp;store it for 7 days. This means you have 7 days to request a certificate for the given domain names with a need to repeat the authentication. </p><p>As you can see there was no word about the actual certificate request yet. The only information Let's Encrypt needed till now was the list of domain names. While it simplifies the API, it also gives us huge flexibility in how we can implement the final step - the actual certificate request. What we need for Step 3 is:</p><ol><li>the address for the "finalize" step (it looks like api.letsencrypt.org/acme/finalize/51135296/308109706)</li><li>the account key</li><li>and of course, the domain names that should be in the certificate.</li></ol><p>This final step is a simple API request - the client sends a CSR and downloads the new certificate. This means that while the validation has to have access to your DND or web server, the Step 3 can be done from anywhere on the internet.</p><h2>KeyChest and Let's Encrypt</h2><p>This flexibility of the ACME protocol is something that KeyChest is exploiting to provide a managed service for companies or those of you who need to manage more than a handful of certificates.</p><ul><li>KeyChest Amp - our open source proxy was the first step that allows collecting logs from all your clients in one place. You can use it as a data source for your own audit systems. KeyChest will add a new web dashboard in the next couple of weeks and you will be able to see the last activity of clients to detect failures and rate limit information. You can download it from GitLab - <a href="https://gitlab.com/keychest/keychestamp/wikis" target="_blank">https://gitlab.com/keychest/keychestamp/wikis</a></li><li>KeyChest AmpX - is another proxy that fully uses the flexibility of the ACME protocol. It creates its own Let's Encrypt accounts to manage certificate renewals while you still keep control over the operations. But it also unifies Let's Encrypt with long-validity certificates. It can decide whether to request a new certificate from Let's Encrypt DigiCert, Comodo, GeoTrust, etc.</li></ul><blockquote><a href="https://keychest.net" target="_blank"><strong>KEYCHEST - HTTPS Exiry Management </strong> - website certificate expiration is easily forgotten—causing costly downtime, our expert service automatically checks and renews your certificates, on time, and correctly, so you can start every day with confidence.</a></blockquote><p><br></p><p><br></p>

Publication Date: 2020-01-24 08:32:00

"Unbreakable" Pen&Paper Encryption

We used one-time pad - the only encryption scheme that is unconditionally secure (no-one can break it - with a small caveat). The real challenge was to create an encryption table that would make it easy for anyone to encrypt and decrypt a message.

<p>A friend came over to our office one day (some years ago) and started talking about the possibility of giving people a chance to encrypt messages without computers, just with a pen and paper. They would write a message, encrypt it by hand, burn/eat/melt the encryption tool (i.e., a sheet of paper), and send the message.</p><h3><a href="https://www.smartarchitects.co.uk/penpaper/script.py" target="_blank">CREATE ENCRYPTION SHEET NOW</a></h3><p>We thought it would be fun to create something useful and so we, eventually, created a procedure and a tool. It was quite easy from the cryptography point of view as <strong><u>we used a one-time pad - the only encryption scheme that is unconditionally secure</u></strong> (no-one can break it - with a small caveat). The real challenge was to create an encryption table that would make it easy for anyone to encrypt and decrypt a message.</p><p>Due to our limitations to read small letters, our encryption sheets only allow to encrypt 50 characters. Longer messages will need several encryption sheets.</p><ul><li>The code is at GitLab - <a href="https://gitlab.com/cyberfun/penpaper/" target="_blank">https://gitlab.com/cyberfun/penpaper/</a></li><li>To print a sheet (it may download a PDF when clicked) - <a href="https://www.smartarchitects.co.uk/penpaper/script.py" target="_blank">https://www.smartarchitects.co.uk/penpaper/script.py</a></li></ul><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Encryption sheet for one time pad" src="/storage/storage/wink/images/yyaDuE7Yj6QrZo7qqcd3Cymv5z4pqXeddExEro9X.png"><p>Encryption sheet for one time pad</p></div><h2>How To</h2><p>To send a secure message, you need a hardcopy of an encryption sheet - that's what this repository is about.</p><p>However, like with any other security, the difference between the smart and silly is how to use the tools you have.</p><p>Here's a "secure procedure" that ensures that noone will be ever able to decipher encrypted messages.</p><h2>Basic Rules</h2><ol><li>You need a set of encryption sheets;</li><li>Each sheet can be used only once. If you need to send 10 messages, you need 10 different sheets (unless you are just testing to see whether it works);</li><li>One sheet allows encryption of a message of up to 50 characters;</li><li>Each sheet contains a code number that needs to be sent with the message - 5 letters that are in large font should be enough - so that the recipient can find the right decoding sheet; and</li><li>Sheets MUST NOT be disclosed to a third party, as that would compromise the message.</li></ol><h2>Basic Use</h2><ol><li>Print as many encryption sheets;</li><li>Fill in the names of people who share an encryption sheet. (1) the person how keeps the decrypting part of the sheet, (2) who will be encrypting/sending.</li><li>Cut the sheet into two - the upper part goes to the sender, the lower part goes to the recipient.</li></ol><h3>Sending</h3><ol><li>Write the message in the top row of empty boxes - maximum is 50 characters - skip spaces or replace them with 'X's;</li><li>For each character, find it in the column beneath it on the left, and write the character next to it into the box at the bottom of the column;</li><li>Once you've done all the characters, destroy everything above the line "CUT HERE - DESTROY UPPER PART"; and</li><li>Send the remaining piece to the recipient directly or type it into an SMS or email</li><li>You have to include the 5 letters of the sheet code - that will help the receiver find the decryption sheet.</li></ol><h3>Receiving</h3><p>Find the sheet with the code as received with a message. Write the received message in the top row of boxes; For each box, find its letter in the left column beneath and write the character next to it in the box at the bottom of the column; You can read the message now (spaces are missing or replaced with 'X's). You should now destroy the whole sheet.</p><h2>How to Use Sheets - Professional</h2><p>The 'professional' means that there is more than 2 people and you use this to send messages between any two of them. You now have to create your key management / sheet management so that encryption sheets don't get compromised.</p><ol><li class="ql-indent-1">Make a list of people who want to encrypt messages with our sheets and note who will want to talk to who.</li><li class="ql-indent-1">Estimate how many messages each pair will send in a month (or other suitable time interval) and write it all down.</li></ol><p>Note: each message requires one sheet and it is a good idea to have a small stock of sheets (too large a stock increases the danger of someone else making a copy and decrypting your messages).</p><ul><li>If you use a web browser to print sheets - switch your web browser to privacy mode so that no copies of sheets remains on your computer.</li><li>Print as many sheets as you need and close the browser when finished.</li><li>On each sheet, name who will keep the decrypting part of the sheet (1) and who will be encrypting (2).</li><li>Write the date after which the sheet should not be used (0).</li><li>Cut the sheet into two - the upper part goes to the sender, the lower part goes to the receiver (as you've just written on the sheet). Ideally, all steps up to now happen when senders and receivers are present.</li></ul><h3>Sending</h3><ol><li>Write the message in the top row of empty boxes - maximum is 50 characters - skip spaces or replace them with 'X's;</li><li>For each character, find it in the column beneath it on the left, and write the character next to it into the box at the bottom of the column;</li><li>Destroy everything above the line "CUT HERE - DESTROY UPPER PART"; and</li><li>Send the remaining piece to the recipient directly or type it into an SMS or email together with 5 letters of the sheet code.</li></ol><h3>Receiving</h3><ol><li>Find the sheet with the sheet code as received with the message.</li><li>Write received message in the top line of boxes;</li><li>For each box, find its letter in the left-hand column beneath it and write the character next to it in the box at the bottom;</li><li>When you've read the message (spaces are missing or replaced with 'X's) destroy the whole sheet.</li></ol><h2>Compromise Response - "Disaster Recovery (DR) Plan"</h2><ol><li>If you have a suspicion that some sheets have been compromised, senders and recipients must destroy all of their unused copies.</li></ol><h3>Management of sheets</h3><ol><li>Define maximum time for keeping printed sheets and destroy them if you do not use them by then.</li><li>You can define further rules for keeping sheets safe and for their destruction in particular circumstances.</li></ol><h2>Security Caveat</h2><p>The unconditional security depends on true randomness of encryption sheets. At the moment, this is ensured by the fact that the generation algorithm is on our server and we make sure that everything is erased when a new encryption sheet is downloaded.</p><p>This however can be improved by:</p><ul><li>using secure hardware, moving server abroad, ... Let us know if you are interested in a hardened version; or</li><li>generate sheets in Javascript on your computer instead on our server - we may do a Javascript version if we feel idle.</li></ul><p><br></p><p>-----</p><blockquote><em>Website certificate expiration is easily forgotten—causing costly downtime, our expert service monitors your certificates automatically and renews them on time, and correctly, so you can start every day with confidence.</em></blockquote><blockquote><em style="color: rgb(51, 85, 187);">While </em><a href="https://keychest.net/auditnow" target="_blank" style="color: rgb(51, 85, 187);"><em>you're here, why don't you have a look at our KeyChest HTTPS expiry management and test your domain for free?</em></a></blockquote><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="" src="https://keychest.net/storage/storage/wink/images/aGOrZzRS6GvAVl5EWpGJddawB1YrCFuiBsSFdktU.png"></div><p><br></p><p><br></p>

Publication Date: 2020-01-16 09:56:00

Massive MS Windows bug - by NSA - how it works (maybe)

Breaking TLS by sending the same thing twice and MS CryptoAPI not checking that both versions are the same.

<p>I have just skimmed a looong discussion at Hacker News - <a href="https://news.ycombinator.com/item?id=22047573" target="_blank">https://news.ycombinator.com/item?id=22047573</a> - about a vulnerability so big that <a href="https://www.us-cert.gov/ncas/alerts/aa20-014a" target="_blank">NSA was happy to be accredited</a>. (I only wonder whether they spotted someone else using it.)</p><p>What does the bug do? It basically allows a random, malicious, server to pretend to be a legitimate server so long as the the latter uses ECC certificate. That completely breaks all the protection provided by HTTPS / TLS. Imagine there is no internet encryption. ... got it? Now imagine what you can do with DNS poisoning, MITM, etc.</p><p>There's a lot of maths and complicated equations, but not really a hint of how the attacker can make MS Crypto API fall for the trap.</p><p><br></p><p><strong><em>Update 16 Jan 10:20am UTC: while the general principle below remains the same, it appears that the bug is related to a validation of certificates in MS Crypto API - rather than TLS handshake. You still need to de-couple the signature and EC parameters and the public key itself. The attack includes tweaking the root CA certificate. There was also an initial hint that CT logs can catch the attack but that is not the case.</em></strong></p><p><strong><em>Saleem Rashid did a PoC of the attack and it works on all browsers except Firefox that uses own crypto library.</em></strong></p><p><strong><em>Initial PoC results - </em></strong><a href="https://twitter.com/saleemrash1d/status/1217495681230954506" target="_blank"><strong><em>https://twitter.com/saleemrash1d/status/1217495681230954506</em></strong></a></p><p><strong><em>A Chrome follow-up - </em></strong><a href="https://twitter.com/saleemrash1d/status/1217519809732259840" target="_blank"><strong><em>https://twitter.com/saleemrash1d/status/1217519809732259840</em></strong></a></p><h3>Preps</h3><p>What is clear - the attacker has to create a new ECC key that has the same public key as in a certificate of the server they want to impersonate. They do it by adjusting the parameters of the elliptic curve. In other words, the public key is the same, but the private key and the elliptic curve is different. </p><p>What does it mean to change the parameters of an ECC? The school maths works with numbers as if they were on a straight line - multiplying by 2 = moving along the line twice the distance from zero. Changing ECC is like bending that line to get numbers next to each other, instead of calculating equations properly.</p><p>OK - so the attacker has:</p><ol><li>a valid certificate from a legitimate server</li><li>own key pair - its public key is the same as the public key in the certificate</li><li>ECC parameters used to calculate the own key pair (private key)</li></ol><h3>Launch</h3><p>All the preps are useless, if we can't make clients (our prey) to cooperate. There aren't many options for the server to force a remote computer to co-operate. It will only "talk" TLS, so the leverage has to be found there.</p><p>One of the TLS algorithms is a combination of ECDHE (Diffie-Hellman) and ECDSA. It should provide "perfect - forward - security". The crypto standards say that both algorithms have to use the same ECC parameters. But each of the algorithms is defined in a different standard, which caused redundancy - the same information - the ECC parameters are sent twice within each TLS/HTTPS handshake.</p><p>ECDHE parameters are sent as part of the ServerKeyExchange message, ECDSA parameters are in the certificate. Validation order should be:</p><ol><li>validate the certificate - verified against a list of trusted root CAs </li><li>extract ECC parameters from the certificate - verified by the cert </li><li>check the signature on TLS message with ECDHE - using the public key of the server</li><li>check the params in the message are the same as ECC parameters</li><li>use the ECDHE with its ECC params</li></ol><p>It seems that MS Crypto API has done it differently: </p><ol><li>validate the certificate - verified against a list of trusted root CAs </li><li>get ECDHE and ECC params - NOT verified </li><li>check the signature on TLS message with ECDHE - using ECC params from (2) and the public key from the certificate</li><li>use the ECDH with its ECC params</li></ol><p>The problem is step (2), which breaks the chain of trust and allows the server to force clients into trusting malicious servers. It's like skipping a few transactions in a blockchain.</p><p><br></p><p>Anyway, that's my take. It looks feasible but maybe the bug was somewhere completely different :)</p><p>-----</p><blockquote><a href="https://keychest.net/auditnow" target="_blank"><em>As you're here, why don't you have a look at our KeyChest HTTPS expiry management and test your domain for free?</em></a></blockquote><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="" src="/storage/storage/wink/images/aGOrZzRS6GvAVl5EWpGJddawB1YrCFuiBsSFdktU.png"></div><p><br></p>

Publication Date: 2020-01-14 22:32:00

ACMEv2 Clients

A list of ACMEv2 (Let's Encrypt) clients with summaries and popularity (if available, e.g., GitHub stars).

<p>As we have analyzed the existing Let's Encrypt clients for internal use, we realized that there is no public list that would also provide basic description with main features. </p><p>We used the list of clients from the Let's Encrypt website as a starting point. Added notes of features that we found of interest and re-classified some of the entries to better reflect the nature of each software.</p><p><em>We will occasionally review the list but if you find an incorrect info, would like to add a missing project, or change anything, do let us know at support@keychest.net. </em></p><h2>Outliers - projects I like for being different</h2><p>There are obvious, popular, clients that you can see mentioned everywhere. Here's a short list of projects - in no particular order - that tried to approach the integration differently. Maybe I also like them as they share something with our <a href="https://keychest.net/letsencrypt" target="_blank">KeyChest</a>.</p><ul><li><a href="https://github.com/leandromoreira/tls_certificate_generation" target="_blank">tls_certificate_generation</a> - a Docker project for renewing certificates for domain that are resolved by internal DNS. It launches a temporary AWS/DO VMs. ... the project looks dead (doesn't seem to support RFC8555 / ACMEv2).</li><li><a href="https://github.com/haproxytech/haproxy-lua-acme" target="_blank">haproxy-lua-acme </a>- an HAproxy client. When you need to renew a certificate, you send a POST request to your HAproxy ... instead of to the LE API directly.</li><li>Greenlock - just because the author has built a whole set of tools written in JavaScript for various use cases - see below. </li><li><a href="https://github.com/myfreeweb/freshcerts" target="_blank">freshcerts</a> - a Ruby project (also not supporting ACMEv2) that creates a centralized service allowing lightweight scripts on endpoints. I suspect that it fails with ACMEv2 as it doesn't allow changing the server address.</li><li><a href="https://man.openbsd.org/acme-client.1" target="_blank">acme-client</a> - the BSD version, well because it is part of the distro.</li><li><a href="https://github.com/hlandau/acmetool" target="_blank">acmetool</a> - the Go project - because it doesn't have any dependency and works as a server listening on port 402.</li></ul><h2>Clients</h2><h3>Bash</h3><p><strong>acme.sh</strong> - <a href="https://github.com/Neilpang/acme.sh" target="_blank">https://github.com/Neilpang/acme.sh</a> - stars: 15,600 - a simple script, tests for a number of platforms. Standalone, nginx, and apache modes.</p><p><strong>dehydrated</strong> - <a href="https://github.com/lukas2511/dehydrated" target="_blank">https://github.com/lukas2511/dehydrated</a> - stars: 4,600 - a strong support of hooks for automation, allows use of custom CSRs</p><p><strong>GetSSL</strong> - <a href="https://github.com/srvrco/getssl/tree/APIv2" target="_blank">https://github.com/srvrco/getssl/tree/APIv2</a> - stars: 1,200 - includes ftp/sftp/ssh capability to copy challenges and certificates to remote servers. Configuration files for multiple servers are stored in subfolders.</p><p><strong>ght-acme.sh</strong> - <a href="https://github.com/bruncsak/ght-acme.sh" target="_blank">https://github.com/bruncsak/ght-acme.sh</a>, stars: 9 - key generation requires a separate use of openssl, computes private key thumbprints to pass to nginx for validation.</p><h3>C</h3><p><strong>acme-client-portable</strong> - <a href="https://github.com/graywolf/acme-client-portable" target="_blank">https://github.com/graywolf/acme-client-portable </a>- stars: 10 - Maintained port of openBDS's acme-client</p><p><strong>Apache mod_md</strong> - <a href="https://httpd.apache.org/docs/trunk/mod/mod_md.html" target="_blank">https://httpd.apache.org/docs/trunk/mod/mod_md.html</a> - manages domain properties for a) renewal of HTTPS certs via ACME and b) offer OCSP stapling.</p><p><strong>Icing mod_md</strong> - <a href="https://github.com/icing/mod_md" target="_blank">https://github.com/icing/mod_md</a> - stars: 255 - an alternate implementation of Apache mod_md with more frequent updates. It provides a) renewal of HTTPS certs via ACME and b) offer OCSP stapling.</p><p><strong>uacme</strong> - <a href="https://github.com/ndilieto/uacme/" target="_blank">https://github.com/ndilieto/uacme/</a> - stars: 59 - lightweight client with only dependencies libcurl and GnuTLS/OpenSSL/mbedTLS. User has to setup and clean up challenges via hooks.</p><h3>C++</h3><p><strong>acme-lw</strong> - <a href="https://github.com/jmccl/acme-lw" target="_blank">https://github.com/jmccl/acme-lw</a> - stars: 7 - only supports HTTP challenges. Dependencies are cmake, openssl, and curl. Staging / Prod is decided during build.</p><p><strong>esp32-acme-client</strong> - <a href="https://esp32-acme-client.sourceforge.io" target="_blank">https://esp32-acme-client.sourceforge.io</a> - (no downloads in 30 days) - work in progress - renewals not supported, tested as part of an author's app.</p><h3>Clojure</h3><p><strong>certificaat</strong> - <a href="https://github.com/danielsz/certificaat" target="_blank">https://github.com/danielsz/certificaat</a> - stars: 77 - optimized for "get a cert, setup cron, forget", config files are in the EDN format.</p><h3>D</h3><p><strong>amce-lw-d</strong> - <a href="https://github.com/cschlote/acme-lw-d" target="_blank">https://github.com/cschlote/acme-lw-d</a> - stars: 3 - install via apt/yum/dub, account creation via an openssl command.</p><h3>Docker</h3><p><strong>tls_certificate_generation</strong> - <a href="https://github.com/leandromoreira/tls_certificate_generation" target="_blank">https://github.com/leandromoreira/tls_certificate_generation</a> - stars: 26 - ACME client for domains that are either resolved with internal DNS or temporary, the use case in the manual uses a temporary AWS/DO machine launched purely for the purpose of issuing a certificate.</p><h3>Go</h3><p><strong>acmetool</strong> - <a href="https://github.com/hlandau/acmetool " target="_blank">https://github.com/hlandau/acmetool </a>- stars: 1,700 - binary releases, dependency-free, listens on port 402 to minimise web server&nbsp;configuration changes.</p><p><strong>autocert</strong> - <a href="https://godoc.org/golang.org/x/crypto/acme/autocert" target="_blank">https://godoc.org/golang.org/x/crypto/acme/autocert</a> - (part of golang crypto) - work in progress, library.</p><p><strong>Lego</strong> - <a href="https://go-acme.github.io/lego/" target="_blank">https://go-acme.github.io/lego/</a> -&nbsp;stars: 3,888 -full implementation of ACMEv2, use of custom CSRs.</p><p><strong>ngxpkg</strong> - <a href="https://github.com/webpkg/ngxpkg" target="_blank">https://github.com/webpkg/ngxpkg</a> - stars: 22 - a CLI client for nginx, configuration via env variables.</p><p><strong>openshift-acme</strong> - <a href="https://github.com/tnozicka/openshift-acme" target="_blank">https://github.com/tnozicka/openshift-acme</a> - client for OpenShift, upgrade to rfc8555 in progress (Jan/2020), client for OpenShift and Cubernates clusters.</p><h3>HAProxy</h3><p><strong>haproxy-lua-acme</strong> - <a href="https://github.com/haproxytech/haproxy-lua-acme" target="_blank">https://github.com/haproxytech/haproxy-lua-acme </a>- stars: 34 - ACMEv2 operations done via POST requests to the proxy, HAproxy has to be manually restarted.</p><h3>Java</h3><p><strong>ACME4J</strong> - <a href="https://github.com/shred/acme4j" target="_blank">https://github.com/shred/acme4j</a> - stars: 298 - JRE8 (101) or higher, maven, dependencies jose4j, Bouncy Castle (for generating keys and CSRs), slf4j</p><p><strong>acme-client</strong> - <a href="https://github.com/porunov/acme_client" target="_blank">https://github.com/porunov/acme_client</a> - stars: 53 - a CLI agent for automation tools or scripts, CLI commands for each ACME API function.</p><h3>Microsoft Azure</h3><p><strong>appservice-acmebot</strong> -&nbsp;<a href="https://github.com/shibayan/appservice-acmebot" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/shibayan/appservice-acmebot</a> - stars: 124 - Win/Linux, Azure Web Apps, Functions, Zone Apex domain certs, wildcard, doesn't use KeyVault.</p><p><strong>AzureWebAppSSLManager</strong> - <a href="https://github.com/n3wt0n/AzureWebAppSSLManager" target="_blank">https://github.com/n3wt0n/AzureWebAppSSLManager</a> - stars: 15 - renewal of certs with Azure DNS challenges, certs are stored in Azure Blob Storage. Required Azure Service Principal and SendGrip API.</p><p><strong>GetSSL - Azure Automation</strong> - <a href="https://www.powershellgallery.com/packages/GetSSL-LetsEncrypt/" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://www.powershellgallery.com/packages/GetSSL-LetsEncrypt/</a> - PowerShell script that works with MS Azure KeyVault. A documentation for MS Azure Vault is at https://github.com/ebekker/foobar/tree/master/docs/platyps. Installation with "Install-Script".</p><p><strong>keyvault-acmebot</strong> - <a href="https://github.com/shibayan/keyvault-acmebot" target="_blank">https://github.com/shibayan/keyvault-acmebot </a>- stars: 100 - this is a "KeyVault" version of appservice-acmebot.</p><h3>Node.js</h3><p><strong>acme2.js</strong> - <a href="https://git.cloudron.io/cloudron/box/blob/master/src/cert/acme2.js" target="_blank" style="color: rgb(64, 64, 200);">https://git.cloudron.io/cloudron/box/blob/master/src/cert/acme2.js</a> - requires 'openssl', one file, no documentation.</p><p><strong>greenlock.js</strong> - <a href="https://git.coolaj86.com/coolaj86/greenlock.js" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://git.coolaj86.com/coolaj86/greenlock.js</a> - stars: 19 - pure JS implementation, several DNS system integrations.</p><p><strong>greenlock-cli </strong>- <a href="https://git.coolaj86.com/coolaj86/greenlock-cli.js" target="_blank">https://git.coolaj86.com/coolaj86/greenlock-cli.js</a> - requires a webserver listening on port 80, default config is "staging", standalone and webroot modes.&nbsp;</p><p><strong>Greenlock Express</strong> - <a href="https://git.coolaj86.com/coolaj86/greenlock-express.js" target="_blank">https://git.coolaj86.com/coolaj86/greenlock-express.js</a> - stars: 31 - several DNS system integrations, examples for Express, Node's http2, websockets, socket.io.</p><p><strong>node-acme-client</strong> - <a href="https://github.com/publishlab/node-acme-client" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/publishlab/node-acme-client</a> - stars: 69 - account private key is set as a JS constant.</p><p><strong>node-acme-lambda</strong> - &nbsp;<a href=" https://github.com/ocelotconsulting/node-acme-lambda" target="_blank">https://github.com/ocelotconsulting/node-acme-lambda</a> - stars: 93 - uses AWS Lambda, certs are stored in S3, environment configuration.</p><h3>Perl</h3><p><strong>Crypt-LE</strong> - <a href="https://github.com/do-know/Crypt-LE" target="_blank">https://github.com/do-know/Crypt-LE</a> - stars: 202 - portable, with Windows binaries available, dependency openssl-devel/libssl-dev, export to PFX/p12.</p><p><strong>p5-Net-ACME2</strong> - <a href="https://github.com/FGasper/p5-Net-ACME2" target="_blank">https://github.com/FGasper/p5-Net-ACME2</a> - stars: 3 - production-grade, own exception class, library with logic examples to build "application workflow".</p><h3>PHP</h3><p><strong>acme</strong> - <a href="https://github.com/kelunik/acme" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/kelunik/acme</a> - stars: 96 - PHPDoc available, installation with composer, uses the Amp framework.</p><p><strong>acme2</strong> -<a href="https://github.com/stonemax/acme2" target="_blank" style="color: rgb(64, 64, 200);">&nbsp;https://github.com/stonemax/acme2</a> - Another PHP client for acme protocol.</p><p><strong>acmecert</strong> - <a href="https://github.com/skoerfgen/ACMECert" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/skoerfgen/ACMECert</a> - stars: 40 - renewals and revocations, cert parsing to extract expiry date, depends on OpenSSL and cURL.</p><p><strong>acmephp</strong> - <a href="https://github.com/acmephp/acmephp" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/acmephp/acmephp&nbsp;</a>- stars: 404 - CLI client, a single binary file, integration with Monolog for notifications, config formatters for nginx, nginx-proxy, haproxy. Configurable to copy certs to remote machines.</p><p><strong>acme_proxy.php</strong> - <a href="https://github.com/jpawlowski/acme_proxy.php" target="_blank">https://github.com/jpawlowski/acme_proxy.php</a> - stars: 1 - ACME challenge validation proxy using localhost DNS results.&nbsp;</p><p><strong>le-acme2-php</strong> - <a href="https://github.com/fbett/le-acme2-php" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/fbett/le-acme2-php</a> - stars: 16 - based on the yourivw/LEClient, rewritten and enhanced.</p><p><strong>leclient</strong> - <a href="https://github.com/yourivw/LEClient" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/yourivw/LEClient</a> - stars: 127 - install with composer, a clear documentation in the README.md file.</p><p><strong>lemanager</strong> - <a href="https://github.com/analogic/lemanager " target="_blank">https://github.com/analogic/lemanager </a>- stars: 91 - containerized app (docker container), has a GUI showing expiry of certs</p><h3>Python</h3><p><strong>acertmgr</strong> - <a href="https://github.com/moepman/acertmgr" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/moepman/acertmgr</a> - stars: 8 - you can define own account key, or it can be generated, rich configuration with 4 "scopes" (global, domain, cmd line, defaults.</p><p><strong>acme-cert-tool</strong>&nbsp;- <a href="https://github.com/mk-fg/acme-cert-tool" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/mk-fg/acme-cert-tool</a> - stars: 2 - single script with 1 dependency (cryptography), python 3.7+.</p><p><strong>acme-nginx</strong> - <a href="https://github.com/kshcherban/acme-nginx" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/kshcherban/acme-nginx</a> - stars: 201 - ACME client for nginx. Includes DNS challenges for AWS route53 and Digital Ocean DNS.</p><p><strong>acme-nosudo</strong> - <a href="https://github.com/diafygi/acme-nosudo" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/diafygi/acme-nosudo</a> - stars: 1,200 - two scripts - sign_csr.py and revoke_crt.py to create/revoke a cert.&nbsp;</p><p><strong>acme-powerdns</strong> - <a href="https://github.com/adfinis-sygroup/acme-powerdns" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/adfinis-sygroup/acme-powerdns</a> - does NOT support rfc8555, but an interesting integration with PowerDNS.</p><p><strong>acme-tiny</strong> - <a href="https://github.com/diafygi/acme-tiny" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/diafygi/acme-tiny</a> - stars: 4,300 - tiny Python client, depends on openssl, account key has to be created separately</p><p><strong>acme-tiny-dns</strong> - <a href="https://acme-dns-tiny.adorsaz.ch/" target="_blank" style="color: rgb(64, 64, 200);">https://acme-dns-tiny.adorsaz.ch</a> - a fork of acme-tiny, only supports DNS challenges, ACME account and CSR have to be supplied.</p><p><strong>acmebot</strong> - <a href="https://github.com/plinss/acmebot" target="_blank">https://github.com/plinss/acmebot</a> - stars: 73 - domains for certificates are defined in a configuration file, default is DNS authorization, creates pinning header (HPKP).</p><p><strong>sewer</strong> - <a href="https://github.com/komuw/sewer" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/komuw/sewer</a> - stars: 102 - library and CLI app, supports several DNS providers (modular to add new ones).</p><p><strong>simp_le</strong> - <a href="https://github.com/zenhack/simp_le" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/zenhack/simp_le</a> - stars: 154 - a fork from kuba/simp_le, which is unmaintained, cmd line parameter setting minimum validity (for renewal to kick in), a docker container.</p><p><strong>txacme</strong> - <a href="https://github.com/mithrandi/txacme" target="_blank">https://github.com/mithrandi/txacme </a>- stars: 38 - an implementation of the ACME protocol for Twisted (event-driven net engine). It is not a client and under heavy development.</p><h3>Ruby</h3><p><strong>acme-client</strong> - <a href="https://github.com/unixcharles/acme-client" target="_blank">https://github.com/unixcharles/acme-client</a> - stars: 380 - a Ruby client as a library, with code snippets to integrate into an application.</p><p><strong>acme-distributed</strong> - <a href="https://github.com/jannfis/acme-distributed" target="_blank">https://github.com/jannfis/acme-distributed</a> - stars: 1 - the main difference - it places challenges on remote servers. Incomplete implementation, outdated docs.</p><p><strong>acmesmith</strong> - <a href="https://github.com/sorah/acmesmith" target="_blank">https://github.com/sorah/acmesmith</a> - stars: 103 - it stores certs and keys in cloud services (e.g., S3).&nbsp;</p><p><strong>chef-acme</strong> - <a href="https://github.com/schubergphilis/chef-acme" target="_blank">https://github.com/schubergphilis/chef-acme</a> - stars: 102 - Chef cookbook for Let's Encrypt, examples of chef configurations.</p><p><strong>combine-acme</strong> - <a href="https://gitlab.com/6318613/combine-acme" target="_blank">https://gitlab.com/6318613/combine-acme</a> - stars: 1 - it not only generates certs but also uploads them got Google cloud (GCP) and Cloudflare.</p><p><strong>freshcerts</strong> - <a href="https://github.com/myfreeweb/freshcerts" target="_blank">https://github.com/myfreeweb/freshcerts</a> - stars: 53 - it is a centralized "server" that allows endpoints used lightweight scripts to request certificates.</p><h3>Rust</h3><p><strong>acme-client</strong> - <a href="https://github.com/onur/acme-client" target="_blank">https://github.com/onur/acme-client</a> - stars: 178 - allows using own keys and CSRs.</p><p><strong>ACMEd</strong> - <a href="https://github.com/breard-r/acmed" target="_blank">https://github.com/breard-r/acmed</a> - stars: 24 - written as a daemon, fully customizable challenge validation, retries, key pair reuse, customizable HTTPS rate limits.</p><p><strong>le-opensrs</strong> - <a href="https://github.com/mhmd3bdo/le-opensrs" target="_blank">https://github.com/mhmd3bdo/le-opensrs</a>&nbsp;- stars: 2 - a client for opensrs DNS, only this DNS challenge validation.</p><h3>Windows/IIS</h3><p><strong>acmesharpcore</strong> - <a href="https://github.com/PKISharp/ACMESharpCore" target="_blank">https://github.com/PKISharp/ACMESharpCore</a> - stars: 130 - .NET library.</p><p><strong>acmesharpcore-powershell</strong> - <a href="https://github.com/PKISharp/ACMESharpCore-PowerShell" target="_blank">https://github.com/PKISharp/ACMESharpCore-PowerShell</a> - stars: 27 - PowerShell library</p><p><strong>autoacme</strong> - <a href="https://github.com/ridercz/AutoACME" target="_blank">https://github.com/ridercz/AutoACME</a> - stars: 71 - .NET, an alternative to letsencrypt-win-simple, Windows&amp;IIS, not requiring admin rights, supports web farms</p><p><strong>certes</strong>&nbsp;- <a href="https://github.com/fszlin/certes" target="_blank">https://github.com/fszlin/certes</a> - stars: 246 - .NET client, CLI app and library</p><p><strong>getcert2</strong> - <a href="https://github.com/GeorgeSchiro/GetCert2" target="_blank">https://github.com/GeorgeSchiro/GetCert2</a> - stars: 6 - CLI and GUI app, it copies certs to LAN storage, updates and restarts SSO acress server farm, creates new IIS websites for new domains in certificates, it is a front-end for "acme-ps".</p><p><strong>posh-acme</strong> - <a href="https://github.com/rmbolger/Posh-ACME" target="_blank">https://github.com/rmbolger/Posh-ACME</a> - stars: 206 - PowerShell, single commands for new/renewing certs, DNS challenge with many providers, pem/pfx output, no admin privilege required</p><p><strong>win-acme</strong> - <a href="https://github.com/PKISharp/win-acme/" target="_blank">https://github.com/PKISharp/win-acme/</a> - stars: 3,300 - binaries available, cmd line application with "menus".</p><p><strong>wincertes</strong> - <a href="https://github.com/aloopkin/WinCertes/tree/master/WinCertes" target="_blank">https://github.com/aloopkin/WinCertes/tree/master/WinCertes</a> - stars: 34 - C# client, auto renewal with Scheduled Task, config in Registry, logs to stdout and files.</p><h2>Applications</h2><p><strong>Caddy</strong> - <a href="https://caddyserver.com" target="_blank">https://caddyserver.com</a> - a web server with in-built certificate renewal.</p><p><strong>FreeSSL.tech auto</strong> - <a href="https://freessl.tech/" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://freessl.tech/</a> - Let's Encrypt app in PHP.</p><p><strong>haproxy-acme-validation-plugin</strong> - <a href="https://github.com/janeczku/haproxy-acme-validation-plugin" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/janeczku/haproxy-acme-validation-plugin</a> - stars: 268 - requires Certbot for renewals, the plugin manages challenge validation.</p><p><strong>Hiawatha webserver</strong> - <a href="https://www.hiawatha-webserver.org/letsencrypt" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://www.hiawatha-webserver.org/letsencrypt</a> - PHP package, no separate documentation is part of the web browser source code, although as a separate package.</p><p><strong>Key Manager Plus</strong> - <a href="https://www.manageengine.com/key-manager/" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://www.manageengine.com/key-manager/</a> - not open source nor free, key management for enterprises, binary downloads for Linux and Win.</p><p><strong>KeyChest AMP </strong>- <a href="https://gitlab.com/keychest/keychestamp/-/wikis/home" target="_blank">https://gitlab.com/keychest/keychestamp/-/wikis/home</a> - a proxy for ACMEv2 that creates JSON logs that can be be analyzed for malfunctions, downtimes, and rate-limits.</p><p><strong>lets-proxy2</strong> - <a href="https://github.com/rekby/lets-proxy2" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/rekby/lets-proxy2</a> - stars: 14 - zero config (includes certs with main domain and www), proxy for shared hosting, Russian manual.</p><p><strong>lua-resty-auto-ssl</strong> - <a href="https://github.com/GUI/lua-resty-auto-ssl" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://github.com/GUI/lua-resty-auto-ssl&nbsp;</a>- stars: 1,500 - OpenResty plugin for Let's Encrypt registration and renewals.</p><p><strong>Mako server</strong> - <a href="https://makoserver.net/articles/Lets-Encrypt" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">https://makoserver.net/articles/Lets-Encrypt</a> - Lua web framework and non-blocking asynchronous sockets in a tiny ready to run application server package.</p><p><strong>ponzu-cms</strong> - <a href="https://ponzu-cms.org/" target="_blank" style="color: rgb(64, 64, 200);">https://ponzu-cms.org/</a> - CMS system with in-built certificate renewal.</p><p><strong>traefik</strong> - <a href="https://containo.us/traefik/" target="_blank">https://containo.us/traefik/</a> - reverse proxy with automatic certificate management.</p>

Publication Date: 2020-01-04 01:45:00

Let’s Encrypt for Companies with KeyChest

Let’s Encrypt has a number of downsides when used on a large scale. It uses modern key management protocols, but the high-level of automation requires management. This is what KeyChest provides.

<p><em style="font-size: 1.1rem;">Let’s Encrypt has a number of downsides when used on a large scale. It uses modern key management protocols, but the high-level of automation requires management. This is what KeyChest provides.</em></p><h2>Unifying HTTPS Management</h2><p>The “zero” cost of Let’s Encrypt certificates is balanced-out with two main downsides: rate limits and short lifetime of certificates. While it’s great to get a free product, it becomes somewhat dangerous when you start relying on it without giving a proper thought to what should happen in 3 months’ time when you need to renew it.</p><p>There is also an adoption barrier as Let’s Encrypt uses an automation for renewals (so called ACMEv2 standard) and it requires a complete change in the way you manage your certificates.</p><p>Nevertheless, Let’s Encrypt is a viable option for HTTPS and other encrypted internet services.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="The US government has been using Let’s Encrypt on its gateways for some time now – a list of domains from just one such certificate." src="/storage/storage/wink/images/3XCtE4wpzgmEo51JrLotQrjrG6CGxNFGwX8QHgHu.png"><p>The US government has been using Let’s Encrypt on its gateways for some time now – a list of domains from just one such certificate.</p></div><p><br></p><p>There are many instances where operational teams choose to deploy a Let’s Encrypt certificate when an important service went down due to an expired certificate or the time left is too short to follow usual purchasing. Now imagine you have hundreds such certificates – how can you keep on top of them all?</p><p>KeyChest is now testing (Dec 2019) a new proxy service, which provides a valuable information about the status of Let’s Encrypt certificates. The use requires a small change to the way you use KeyChest agents – Certbot by setting an HTTPS_PROXY. If your existing command is “certbot renew”, the new version would be:</p><blockquote><code>“export HTTPS_PROXY=https://test.keychest.net:6443; certbot renew”</code></blockquote><p>KeyChest will start logging all your requests and create statistics of your usages of Let’s Encrypt. You will instantly get information about the activity of your Certbot agents and detect issues when they happen – not when your certificates start expiring.</p><p>This also helps to comply with Let’s Encrypt rate limits, some of which are fairly strict:</p><ol><li>maximum of 5 new certificates per domain per week;</li><li>50 certificates per registered domain per week;</li><li>300 new “orders per account per 3 hours; or</li><li>5 failed validations per account per hour.</li></ol><h2>Deep Let’s Encrypt Proxy</h2><p>While the monitoring will get you on top of your Let’s Encrypt usage and reduce the risk of downtimes. Our ambition is to unify ACME and “legacy” certificate issuers.</p><p>We achieve that with a deep proxy that does the actual communication with the Let’s Encrypt issuing servers and also validation challenges.</p><p>This allows us to forward certificate requests to Let’s Encrypt, Comodo, Symantec, … or any other certificate issuer according to your requirements. To further simplify your IT operations, our proxy architecture allows endpoint agents to be much smaller with fewer dependencies and installation issues.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Keychest agent – one internal proxy per network, is a single gateway with an access control to minimize any new additional risk." src="/storage/storage/wink/images/Avk6zbPWHCEcf2AocOvUBB7Vao0OaUdbI5YbePhx.png"><p>Keychest agent – one internal proxy per network, is a single gateway with an access control to minimize any new additional risk.</p></div><p>You can either forward (an HTTP reverse proxy) validation requests directly to the KeyChest service, or use our lightweight agents available to the Small Enterprise customers.</p><p>Many companies are considering switching to Let’s Encrypt. What we offer is a management service to keep your commercial certificates while simplifying the configuration of your servers and preventing downtimes.</p><p>KeyChest has a complete database of all internet certificates and can automatically start monitoring any new servers and services you create – providing you with ongoing 100% coverage of your registered domains.</p><p>If you have any question, fire away: info@keychest.net, +1 512-696-1552 or check online: <a href="https://keychest.net" target="_blank">https://keychest.net</a></p>

Publication Date: 2019-12-03 13:53:00

Certificate Monitoring - HTTPS/TLS

There are so many tools to help you ensure that all your HTTPS and other secure services are up and running. You may have just one website or you create a number of web APIs every day. Here you can find a selection of tools we have found and that we see as competitors to our KEYCHEST.

<p>As we continuously improve our own certificate management service, we keep an eye on other tools. There is a wide range of services and each of us has different requirements and preferences.</p><p>When you use Let's Encrypt certificates, it’s perfectly alright to trust your cron and your favorite Let’s Encrypt client to renew your server’s certificate when it’s due. However, this doesn't really work when the number of servers reaches 10-20 or when your job depends on keeping all certificates up to date. Renewing a certificate involves many moving parts so it really is a good idea to continuously check that all keeps working perfectly.</p><p>When the HTTPS really matters to you, the good good practice is to set up an end-to-end monitoring.</p><p>The following text includes some multi-purpose cloud services, dedicate HTTPS cloud services, FOSS projects, as well as several commercial systems.</p><h2>Certificate Cloud Services - Free Usage</h2><p><a href="https://keychest.net/register" target="_blank">KEYCHEST</a> - Let me get our own KeyChest off my chest first. It currently offers a free plan for non-business users with up to 500 endpoints. It uses its own global database of all certificates so it can find all your subdomains automatically (set up and forget service). You will get weekly email reports, an integration API, and a web dashboard. You can also use our automated cert issuance. Paid plans include custom root certificates, additional reports (phishing threat, security report), and internal cert management.</p><p><a href="https://certificatemonitor.org" target="_blank">CertificateMonitor.org </a>- it's an alternative to the default Let's Encrypt email reminders. It does not have any dashboard, you simply give it a domain name and the service will start sending reminder emails.</p><p><a href="https://letsmonitor.org" target="_blank">LetsMonitor.org</a> - it's a free service for the first few domains. You need to enter each domain separately. It has a clear dashboard and email reminders.</p><h2>Standalone Applications - Free</h2><p>There is a large number of standalone applications (GitHub or other FOSS projects) for monitoring:</p><p><a href="https://github.com/drtoful/certinel" target="_blank">Certinel</a> (GitHub, lust update 2017) - It has been created, because Let's Encrypt certificates are only valid for 90 days and there's no automation or monitoring currently available to check. You can do automation with some cronjobs, but this is probably unreliable so it's better you monitor the status of your certificates. Certinel also provides a simple one-page monitoring page were you can add, remove and check the status of your domains.</p><p><a href="https://github.com/srvrco/checkssl" target="_blank">Checkssl</a> (GitHub, last commit March 2019) - With the good work by "Let’s Encrypt" in providing free SSL certs for users, I wanted a quick way to check all the domains I look after to determine which ones have correct SSL certs, and which ones are in need of updating etc.&nbsp; This bash file is the first draft of a program to do that.&nbsp;It can either be run against a list of file names, from the directories in your Lets Encrypt live directory or on a single server with&nbsp;the aim of getting all the domain names from the server.</p><p><a href="https://github.com/sahsanu/lectl" target="_blank">lectl</a> (GitHub, last commit Aug 2018) - Script to check issued certificates by Let's Encrypt on CTL (Certificate Transparency Log) using https://crt.sh . It is directly dependent on the https://crt.sh service, which is managed by SectiGo.</p><p><a href="https://github.com/Matty9191/ssl-cert-check" target="_blank">SSL-cert-check</a> (GitHub, last commit Apr 2019) - a Bourne shell script that can be used to report on expiring SSL certificates. The script was designed to be run from cron and can e-mail warnings or log alerts through nagios.</p><h2>Certificate Only - Commercial Solutions</h2><p><a href="https://www.globalsign.com/en/blog/new-certificate-inventory-tool/" target="_blank">GlobalSign Inventory</a></p><p><a href="https://www.digicert.com/discovery-tool.htm" target="_blank">DigiCert certificate inspector</a></p><p><a href="https://sslmate.com/certspotter/pricing" target="_blank">SSLMate - Cert Spotter</a></p><p><a href="https://isitworking.info/" target="_blank" style="color: rgb(64, 64, 200); background-color: rgb(255, 255, 255);">Is It Working</a></p><p><a href="https://www.appviewx.com/products/cert/" target="_blank">AppViewX</a></p><h2>Multi-Purpose with SSL - Commercial Solutions</h2><p><a href="https://www.statuscake.com/" target="_blank" style="color: rgb(64, 64, 200);">StatusCake</a> has a simple certificate monitoring feature that sends reminders one week before expiration. You have to add each URL separately so it will work best if you have a few web services that are important for you.</p><p><a href="https://sucuri.net/website-security-platform/signup/" target="_blank" style="color: rgb(64, 64, 200);">Sucuri</a> - this service provides annual subscription plans with SSL included from the "Pro". However, this only includes one website. If you have more websites, you'd need to ask about the "Enterprise" option. The price reflects a range of tools offered (malware scan, SQL injection, blacklist monitor, etc.)</p><p><a href="https://www.dotcom-monitor.com/pricing/" target="_blank" style="color: rgb(64, 64, 200);">Dotcom-Monitor</a> is primarily uptime&amp;performance monitoring service. SSL checks include basic info about the certificate (the issuer, name in the cert, if revoked, ...). You need "web services view", which is free for 5 URLs. The maximum number of domains is 100 which goes for $100/month. </p><p><a href="https://www.manageengine.com/products/applications_manager/ssl-certificate-monitoring.html" target="_blank">ManageEngine SSL cert monitoring</a></p><p><a href="https://www.solarwinds.com/server-application-monitor/use-cases/ssl-certificate-monitor" target="_blank">Solarwinds SSL cert monitor</a></p><p><a href="https://www.monitis.com/support/uptime-monitoring/ssl-certificate-monitoring" target="_blank">monitis SSL certificate monitoring</a></p><p><a href="https://www.uptrends.com/products/ssl-certificate-monitoring" target="_blank">Uptrends SSL cert monitoring</a></p><p><a href="https://www.site24x7.com/ssl-certificate-monitoring.html" target="_blank">site24x7 SSL expiry monitoring</a></p><p><a href="https://www.poweradmin.com/help/pa-server-monitor-8-0/howto_monitor_ssl_expiration.aspx" target="_blank">PA Server Monitor</a></p><p><a href="https://www.rapidspike.com/pricing/" target="_blank">RapidSpike</a></p><p><a href="https://redkestrel.co.uk/products/certalert/" target="_blank">RedKestrel CertAlert (Windows)</a></p>

Publication Date: 2019-11-28 11:35:00

Let's Encrypt Uptime - 2 years on

We look at the uptime and reliability of Let's Encrypt services. This is a follow-up activity to our 2017 analysis of Let's Encrypt downtimes from it's beginning.

<p>I have looked at the service disruptions of Let's Encrypt back at the end of 2017. Two years on, I had another look - and compared twelve months periods.</p><p>Let's Encrypt has been a new service that launched in mid-2016. One would naturally expect that first 12+ months were a bit bumpy as the technology, including the infrastructure, settles in. So I was curious how things changed since.</p><p>I used the same source as the first time - <a href="https://letsencrypt.status.io " target="_blank" style="background-color: rgb(255, 255, 255);">https://letsencrypt.status.io</a>. The records seem to be fairly reliable. However, it appears that on several occasions the time of an incident starts when a report is received rather than the time potentially provided by the reporting party. I would not expect that to have a large impact but I wonder if there's a need for an independent uptime monitoring.</p><p>A number of incidents are labeled as "partial" without any further information about the scale of the impact - does it mean longer latency but the provided services are still fully available, does it mean that a certain fraction of API calls fail or is the impact limited, e.g., geographically?</p><p>The history of the Let's Encrypt status over the last 12 months (20 Nov 2018 to 20 Nov 2019) contains 95 records, from which 77 relate to the production services. I ignore non-core services, e.g., web site.</p><h2>Planned Upgrades</h2><p>When you look at the Let's Encrypt status history, you will immediately notice a fairly large number of upgrades. There is in fact 46 Boulder upgrades, which sounds like an incredibly high number.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Planned upgrades of Let's Encrypt production services. Multiple upgrades per month are stacked." src="/storage/storage/wink/images/kihG3ywBhQWZtu3L1OVdk2epH4UtjC7oW0SPbYFB.png"><p>Planned upgrades of Let's Encrypt production services. Multiple upgrades per month are stacked.</p></div><p>As far as I could see, none of them caused any downtime and my main observation is that while the total number is surprisingly high, the team has certainly mastered the upgrade process and is able to quickly react to potential incidents. Below is a similar graph from 2017. While the number of upgrades is similar, it is clear that the time required for each upgrade as stabilised. Which means much better reliability of upgrades.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Let's Encrypt upgrades in 2017. Multiple upgrades per month are stacked." src="/storage/storage/wink/images/N0PjBzwgN99w8bbrc6EpH4TQkLQ0iT9pHXslNv2x.png"><p>Let's Encrypt upgrades in 2017. Multiple upgrades per month are stacked.</p></div><p><em>Note: the chart above is the only in with linear Y-axis. I used logarithmic axis in the following charts to improve the visibility of short outages in the presence of large outliers.</em></p><h2>Full Disruptions</h2><p>The most important aspect, from users' point of view, is the probability of full service disruptions. This directly impacts the overall reliability of certification services and it is one of the main selling points for commercial CAs. Many of them like to quote their 99.99% or higher uptime. </p><p>Let's Encrypt has significantly improved over the last 2 years in terms of the number of incidents. Although it's still quite some distance behind commercial CAs (although they don't publish their incident data).</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Full Disruptions in minutes (logarithmic scale)." src="/storage/storage/wink/images/VYQnIKjRkeZWLlrrXoFnKCW5k9FrA2PUv2cOMOnN.png"><p>Full Disruptions in minutes (logarithmic scale).</p></div><p>You can see that the length of downtimes is relatively short. These include at least 3 instances of downtime related to maintenance - one infrastructure and two on the application level. The overall uptime in 2019 is 99.92%, which is better than the figure I found in 2017 (99.86 - with 99.9% over the second part of the interval analyzed then) - see below. </p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Full service disruptions in 2017. Logarithmic scale for the durations." src="/storage/storage/wink/images/ZNat4hyWDzp3XJuWfuHo0mINdkgiB6GajSPCBxol.png"><p>Full service disruptions in 2017. Logarithmic scale for the durations.</p></div><p>The 2019 incidents include a couple of issues with OCSP responder. This is a fairly critical part of the LE services as it may result in unavailability of websites if browsers require OCSP validations.</p><h2>Partial Disruptions</h2><p>The final part of my comparison is partial disruptions. It is less transparent as the comparison is very blunt and lacks the detail of the impact of particular incidents. Nevertheless, I was somewhat surprised that the downtime was still relatively high.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Partial Disruptions of Let's Encrypt in 2019. Multiple incidents per month are stacked." src="/storage/storage/wink/images/nlkIHJcM3mVd2ST2gG6REbRJJV3yIe82sPNOE4sG.png"><p>Partial Disruptions of Let's Encrypt in 2019. Multiple incidents per month are stacked.</p></div><p>The combined uptime figure (all services fully functional) is only 96.4%, which is lower than what I found in 2017, when the figure stood at 98% (again, the 2017 chart is below).</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Partial disruptions of Let's Encrypt in 2017. Y axis is logarithmic." src="/storage/storage/wink/images/EblYk325BIGRcvoJQob44VuRKh6avnrH1BPcB2qj.png"><p>Partial disruptions of Let's Encrypt in 2017. Y axis is logarithmic.</p></div><p>It's worth mentioning that the 2019 results are significantly affected by a couple of incidents that lasted several days. One of them was caused by a <a href="https://community.letsencrypt.org/t/lets-encrypt-uptime-comparing-2019-with-2016-17/107114/8?u=dancvrcek" target="_blank">migration to another CDN</a> (details provided by "_az"). If we exclude one of both of these partial outages, the uptime is <span style="color: rgb(34, 34, 34);">97.9% and 99.7% respectively. </span></p><h2><span style="color: rgb(34, 34, 34);">OCSP</span></h2><p>I have not charted OCSP outages separately for two reasons. Firstly, I can see only two of them (one full, one partial). Secondly, these outages where short - 5 and 7 minutes and it's not clear to me whether they cover the whole outage or whether the measured interval starts only when the LE team started investigating it.</p><p>If we assume the logged times are accurate, the overall uptime of OCSP responders would be &gt;99.99%.</p><h2>A Final Note</h2><p>Looking at the data and charts above, the main question of mine is whether Let's Encrypt can ever reach the reliability of commercial CAs nor whether LE has such an aspiration. </p><p>LE's main feature is automation. While we generally don't mind if a certificate is renewed today or a week later, the relatively low uptime is a concern. Especially as there are no official service level guarantees.</p><p>This "exercise" made me also wonder whether it makes sense to implement an uptime monitoring system that would provide an independent uptime data. LE issues around 1.3 million certificates a day so every one minute downtime impacts over 900 certificate requests. Similarly, 1 minute downtime of OCSP responders is significant as 50-60% of websites use Let's Encrypt certificates. Arguably, these websites will not include any of the large one but still.</p><p><br></p><p><em>This analysis was created by Dan Cvrcek, a founder of </em><a href="https://keychest.net" target="_blank"><em>KeyChest</em></a><em> - TLS expiry monitoring service with a global database of all certificates and automation of certificate issuance.</em></p><p><br></p><p><br></p>

Publication Date: 2019-11-24 17:37:00

Minerva Attack and Humble Beginnings

ROCA Attack has impacted more than 25% of TPM chips - chips that provide secure boot in laptops, PC, servers of all types. That was in 2017. This year, the same team discovered a new vulnerability that impacts a number of software libraries widely used in open source and commercial projects, using Elliptic Curve encryption.

<p>Do you remember ROCA attack - the most devastating attack in 2017 that extracted secret keys from 25% of TPM module? It has a kind of a sibling - Minerva. While ROCA was about the RSA encryption, MINERVA is about Elliptic Curve (ECC) signing.</p><hr><p>TLDR: a bunch of open source encryption libraries leak Elliptic Curve signing key. Quite a few widely used libraries were bitten (libgcrypt, wolfSSL, MatrixSSL, SunEC/OpenJDK, Crypto++). Check your projects and upgrade if at all possible.</p><h3>First Signs of Problem</h3><p>It seems that the Minerva attack came to light when the research team in Brno were playing with old IDProtect Athena cards. They discovered a correlation between key lengths and timing. This allowed them to eventually recover the whole private key with relatively small number of signatures.</p><blockquote>The details of the attack are available from&nbsp;<a href="https://minerva.crocs.fi.muni.cz/" target="_blank" style="color: rgb(0, 123, 255);">https://minerva.crocs.fi.muni.cz/</a></blockquote><p>This first version of the attack was against specialist security chips. It took around 30 minutes due to slow communication speeds of the chips that would not allow more than 10 signatures per second. Indeed, the number of operations required was only 11,000.</p><p>Athena SCS IDProtect that was successfully attacked was approved for use in the&nbsp;<a href="https://www.securetechalliance.org/athenas-idprotect-smart-card-and-middleware-approved-for-us-government-pivhspd-12-deployment/" target="_blank" style="color: rgb(0, 123, 255);">US government as PIV cards in 2008</a>. However, these chips are not really being sold any more and I would also expect only a low number to be still in use. </p><p>The core problem exploited by the attack is a leakage of the length of numbers used in multiplications of ECDSA/EdDSA. When the multiplication is optimized, it will cause different timings and this can be measured from outside - it's easiest on the same processor but successful attacks were demonstrated when using network loopback or even across local networks. Each such measurement leeks information about the key and the Minerva attack requires between just hundreds of measurements, in some cases, to over hundred thousands. </p><p>So - is the attack just an academic issue or is it a sign of a wider problem? After all, some developers like to optimize their code ...</p><h3>Expanding The Impact</h3><p>While the impact of the original attack was small, the team had a brilliant idea – what about testing the attack against software libraries. I would expect they were taken aback when they found quite a few popular libraries to be vulnerable.</p><ul><li><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13627" target="_blank" style="color: rgb(0, 123, 255);">CVE-2019-13627</a>: Vulnerability in&nbsp;libgcrypt.</li><li><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13628" target="_blank" style="color: rgb(0, 123, 255);">CVE-2019-13628</a>: Vulnerability in&nbsp;wolfSSL/wolfCrypt.</li><li><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13629" target="_blank" style="color: rgb(0, 123, 255);">CVE-2019-13629</a>: Vulnerability in&nbsp;MatrixSSL.</li><li><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2894" target="_blank" style="color: rgb(0, 123, 255);">CVE-2019-2894</a>: Vulnerability in&nbsp;SunEC/OpenJDK/Oracle JDK.</li><li><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14318" target="_blank" style="color: rgb(0, 123, 255);">CVE-2019-14318</a>: Vulnerability in&nbsp;Crypto++.</li></ul><p>Most of them have been fixed in upgrades over the&nbsp;summer, but&nbsp;I’m pretty sure that there will be zillions of projects that will rarely upgrade versions of cryptographic libraries. So the impact may be long-term with smaller attacks to keep coming&nbsp;over&nbsp;many coming years. The list of libraries tested and found safe includes:</p><ul><li class="ql-align-justify">OpenSSL 1.1.1d</li><li class="ql-align-justify">BouncyCastle 1.58</li><li class="ql-align-justify">BoringSSL 974f4dddf</li><li class="ql-align-justify">libtomcrypt 1.18.2</li><li class="ql-align-justify">Botan 2.11.0</li><li class="ql-align-justify">Microsoft CNG</li><li class="ql-align-justify">mbedTLS 2.16.0</li></ul><p>While I was in no way connected to this attack, I like to think it all started in 2002.</p><h3>Humble Beginnings</h3><p>Back in 2002/3, mesmerised by successful side-channel attacks on internet encryption protocols, I decided to build a tool for systematic research and validation of some of these attacks. The result was an analytic toolkit for timing and power analysis of security chips.</p><p>I remember sleepless nights trying to get the tool measure, instead of burning the chips, desperation, and an eventual success.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="SCSAT04 - a 2nd generation of the side-channel analysis tool" src="/storage/storage/wink/images/IYCpCgaWkDRwiuWrXo4quZ7rNjAUImtz0bAfpcs8.jpeg"><p>SCSAT04 - a 2nd generation of the side-channel analysis tool</p></div><p>At the time I thought that just the timing attack has been a bit low-level, easy to defend against, and we really needed to combine it with other types of attacks power / glitch attacks. The SCSAT tools were designed to generate microsecond, high voltage peaks on power, clock, and data pins of chips. This was coupled with up to 200Mps, 12bit samples with microsecond trigger. The goal was to induce computational errors without triggering protection mechanisms of the high-security chips we were looking at.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="The 1st generation of the tool in use" src="/storage/storage/wink/images/olgC4GY42Lp0dZfMNmQAGBzatmMqwsjmq724Y8GZ.png"><p>The 1st generation of the tool in use</p></div><p>The main memory of mine is of long hours of relentless work and it’s absolutely amazing that what we have started many years ago has been turned into absolutely fascinating results by&nbsp;<a href="https://crocs.fi.muni.cz/people/svenda" target="_blank" style="color: rgb(0, 123, 255);">Petr Svenda</a>&nbsp;and his team.</p><p><br></p><p>By: Dan Cvrcek, founder of <a href="https://keychest.net" target="_blank">KeyChest</a>.</p><p><br></p>

Publication Date: 2019-11-22 08:02:00

Automating HTTPS Issuance in KeyChest

KeyChest has automated issuance of first certificates this week. It makes the process as simple as possible with great certificate prices.

<p><a href="https://keychest.net/" target="_blank" style="font-size: 1.1rem; background-color: rgb(255, 255, 255); color: rgb(0, 123, 255);">KeyChest’s</a>&nbsp;business model is based on the management of HTTPS expiry. Automation of certificate issuance is for us an additional service that moves it closer to a complete service to manage your internal and external certificates. What it means in practical terms is that we simply pass on our cost of certificates to all paying users of KeyChest.</p><p>In terms of user experience, our primary goal was to make issuance of new certificates as simple as possible while preserving enough flexibility for the more technical users.</p><p>Let me start with the simple flow. The first step is to register a payment card. We need to pay issuers and so we need to charge you as well. This step will also add default values for the “company”, which are needed for certificate requests.</p><p>The actual certificate request starts with you entering one or more domain names. It can be single domains, or wildcard domains.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="KEYCHEST - issuance of new certificates" src="/storage/storage/wink/images/YhNzRXCVY7hSUoQfk0KVqKbNM7n5lWjhwpPEY0cK.png"><p>KEYCHEST - issuance of new certificates</p></div><p>KeyChest will automatically select products that satisfy your domain names and calculate expected pricing. You simply select the most suitable product from this list.</p><p>We believe that email validation of requests is the preferred method wherever it’s possible. KeyChest will therefore obtain a list of allowed email addresses from a certificate issuer and you again simply select one from a list.</p><p>We are now ready to create the actual request. This happens completely in your browser. Once you enter a password to encrypt a new private key, KeyChest will generate a new key, create a request (PKCS#10 / CSR), and encrypts the secret part of the key with your password.</p><p>You can choose whether this secret key is stored on your disk or in the KeyChest database. Either way, a copy is stored in the local storage of your web browser. The request is then immediately sent out to initiate its validation by the issuer.</p><p>At this point, you need to complete required validation steps – in most cases this would involve following instructions sent via email. KeyChest will keep checking the request status and download the new certificate as soon as it is available. It will also send a notification if configured.</p><p>Voila – at this moment, you have all you need to install the new certificate on your server and KeyChest helps automating it.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="With one click, you can download files for Linux and Windows servers" src="/storage/storage/wink/images/W8ZE65gcdKumnsUiLepbWcv9vuV5ts0zN1Q3p2tm.png"><p>With one click, you can download files for Linux and Windows servers</p></div><p><span style="color: rgb(33, 37, 41);">You can open your Orders and select the one you need. If your target server is an IIS, you click on “Download All as PFX”, enter a password to open the private key (if it’s still in your browser storage, it will be automatically found). Click the same button again and you get a password protected file you can import to IIS. It contains all the certificate and the key. The next step is simply to update the 443/https binding on your web site.</span></p><div class="inline_html" contenteditable="false"><iframe src="https://player.vimeo.com/video/374413887" width="640" height="414" frameborder="0" allow="autoplay; fullscreen" allowfullscreen=""></iframe> </div><p><span style="color: rgb(33, 37, 41);"><span class="ql-cursor"></span></span></p><p>You can see that we avoid sending any secrets over the network. However, you may not want to copy your secret/private key away from where it should be used. Possibly, you already have a CSR file and want to use that instead.</p><p>If this is the case, you simply upload your CSR at the beginning of the certificate request. You don’t have to fill in domain names – they are in the CSR – and you can simply select the product and send the request to the issuer.</p><p>Once the new certificate is ready, you can download the certificate files and install them on your server.</p><p>Most domain-validated certificates will take a couple of minutes from entering a domain name to downloading a complete bundle for your server. The financial side is automated as well so you can download an invoice at the same time, if you need one.</p><p>At the time of publishing:</p><ol><li>COMODO — $6.53</li><li>THAWTE — $25.07</li><li>GEOTRUST — $49.79</li><li>RAPIDSSL — $9.62</li><li>SECTIGO — $40.52</li></ol><p><br></p>

Publication Date: 2019-11-21 10:10:00

KeyChest – Unifying Public and Private Keys

KeyChest has started as an easy to use HTTPS monitoring service. What we are aiming for is a general purpose key management service, which can look after your public as well as internal web encryption keys.

<p>KeyChest has started as an easy to use HTTPS monitoring service. What we are aiming for is a general purpose key management service, which can look after your public as well as internal web encryption keys.</p><p>Ever since KeyChest got its first users, we were asked if it can be used for internal keys. Our initial approach was to provide on-premise instances, which gave potential users a complete autonomy in terms of separate database and dedicated processing power. This is what we still offer as the Enterprise option. But this option asks a lot from users as they have to, at least to some degree, look after their KeyChest.</p><p>As we developed new features it became obvious that we need another option – more flexible, lightweight, low-maintenance. That’s where independent agents, extending the reach of KeyChest audit engines, come from. As we are close to launching KeyChest agents, here’s an introduction.</p><p>Agents will be generally available from the beginning of July 2019.</p><h2>Proxy Agent</h2><p>We wanted agents to be as small and platform-independent as possible. The smaller they are, the easier they are to install, maintain, and update. The platform independence means there is almost no encryption inside (except for an ability to create a secure encrypted channel). Neither it can use low-level networking or other platform-dependent support. Agents will still have to be able to read / write to files and connect to the main KeyChest service, but even file-system access has to be limited to common functionality.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Communication and block diagram of KeyChest agents." src="/storage/wink/images/778XBs0QtPgdumuxZolrUXS8BwrLwPLPVa6bzduF.png"><p>Communication and block diagram of KeyChest agents.</p></div><p><br></p><p>The core of KeyChest agents comprises the following 3 subsystems:</p><ol><li><strong>Logging</strong>&nbsp;– a robust logging, which stores activity logs locally as well as posts them to the KeyChest service is simply a must for efficient management. Detailed information is what you need when in trouble – whether it’s for KeyChest users or for our support helping you out.</li><li><strong>Proxy operation</strong>&nbsp;– the actual audit of secure services requires a strong control over the networking, something that is platform dependent and we are regularly updating it. It means agents must work as transparent proxies for traffic generated by the KeyChest Audit Engines.</li><li><strong>Local control</strong>&nbsp;– agents are gateways into your internal networks and we want to give you as much control as possible over what they can be used for. We are putting restrictions on the ports they can connect to, the address ranges they can use, and so on. This information is in local configuration files, which can be locked-down so only you can change them. We also plan to give as wide access to the source codes of agents as possible.</li></ol><h2>Logging</h2><p>We see logging and ability to audit collected logs as one of the most important aspect of any software and network services. When we started implementing the agents, the first thing we did was a robust logging framework.</p><p>Logging produces JSON formatted messages that provide much better quality of “raw” data. This has massive implications on log audits as all the parameter values from logs are natively stored as separate indexed items. (Internally, we use Splunk for audits. Since we started using JSON logs, visualization and inspection of tens or hundreds of thousands log records were actually fun. The simplicity of selecting any of the log parameters and focus analysis around them gives you a good chance to spot irregularities and issues to look into.)</p><p>The success of any audit of logs depends on the quality of the data and being able to quickly identify where it came from. Each log entry therefore contains:</p><ul><li>time of logging</li><li>time of event</li><li>event code – severity of the message and a unique code (e.g., ERR0043)</li><li>host machine – name and its IP address</li><li>version of the software (agent); and</li><li>process – if the software uses multiprocessing.</li></ul><h2>Proxy Operation</h2><p>This is possibly a more interesting part of KeyChest agents and it still amazes me how simple can it look from outside.</p><p>Each agent controls the traffic and any requests coming from the KeyChest.net service. Details of audit requests are sent to agents so they can block those not complying with agent’s local configuration file.</p><p>Agents regularly connect to keychest.net to request audit “jobs”. When they receive a valid description of an audit job, they will launch a proxy, which connects to the audit target (downstream) and to KeyChest (upstream). Once the audit is completed, the proxy is terminated and the agent can re-use its port.</p><p>Internal network discovery is treated separately. We plan to implement a range of discovery methods based either on:</p><ul><li>internal database of certificates (e.g., LDAP storage of your PKI system); or</li><li>internal DNS zone.</li></ul><p>Discovered services are sent to the KeyChest service so it can start scheduling regular audits.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Communication diagram of KeyChest agent in the reverse proxy mode " src="/storage/wink/images/sQ2qkrWhx9mUZ3WAhaLGFz0ICtFHWa15ApZsBskq.png"><p>Communication diagram of KeyChest agent in the reverse proxy mode </p></div><h2>Agent Installation</h2><p>Agents are provided as one-file packages. You can run them by hand or invoke them with a scheduler like Linux cron. When it’s started for the first time, it will create an initial configuration and will try to register with KeyChest. Once completed, the agent will have its own unique API key and ID, which is in the form of an email address.</p><p>It will occasionally push its configuration to the KeyChest service, but nothing else will happen until it is associated with a KeyChest account. Once that happens, the service discovery and regular audits will commence automatically.</p><p><br></p>

Publication Date: 2019-06-24 10:02:00

KeyChest and Reliability

Those who have been with us for a while may know that we change the cloud provider to Digital Ocean in January. At the same time, we started experimenting with HA database cluster. And we learnt a lot.

<p>Those who have been with us for a while may know that we change the cloud provider to Digital Ocean in January. At the same time, we started experimenting with HA database cluster. And we learnt a lot.</p><p>A wise man would say that you learn most from mistakes and it's true that if things simply work, you are likely to be caught off-guard. We have been experimenting with HA database clusters for several months and believed we mastered the technology. Well, you can judge for yourself in this <a href="https://magicofsecurity.com/mysql8-cluster-and-networking-problems/" target="_blank">blog post of mine</a> :) One big lesson however was that you can't do much without information.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Netdata provides an excellent source of real-time system data." src="/storage/wink/images/ExX2VCY58lIiSEAzmTKNuxWXwyyjiR3CG86f0Mr8.png"><p>Netdata provides an excellent source of real-time system data.</p></div><p>We have eventually decided to use Netdata, which so far satisfied all our requirements. We can access detailed reports when we need them, all alarms are forwarded to our Slack and we have also included alarms and main system stats to the KeyChest web site. You can access those at <a href="https://keychest.net/status" target="_blank">https://keychest.net/status</a> . This page also includes notes about problems and planned system upgrades when we expect downtimes or issues.</p><p>Another aspect of the KeyChest monitoring is access to the application logs. We have completely re-factored logging in the KeyChest audit engine. The aim was to create data that is easy to analyse and query. We have decided to go for the JSON format, with simple text messages and separate parameters and implemented a new log dispatcher that collects logs from multiple audit processes.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="" src="/storage/wink/images/Xf9g3ndqb1yPAHX3e11ZdezDR4hAuvwYTR8COq3R.png"></div><p>Each log message uniquely identifies its source and the version of the KeyChest. It has two timestamps so we know when the logged event happened and when it was added to logs. All variable parameters are defined as separate JSON data items so we can automate analysis with very little loss of detail.</p><p>The analysis is crucial for effective use of any logs. In our case, we store logs locally in files to ensure they don't get lost due to networking issues and we also push the data to a Splunk instance for visualization and querying.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Splunk visualisation of memory use by KeyChest audit engine" src="/storage/wink/images/Alqm9WbBU1fi6fRTEo3uKIvf1EMsnP3oLwtuJTTZ.png"><p>Splunk visualisation of memory use by KeyChest audit engine</p></div><p>We really do put a lot of effort into making KeyChest a reliable service. Sometimes it feels like everything is stacked against us but we are making it better week by week. So if something doesn't work it only means we missed something and we'd love to hear from you!</p><p><br></p><p><br></p>

Publication Date: 2019-06-17 13:58:00

Can blockchain remove the need for an SSL certificate authority?

Blockchain is basically a chain of signatures. You create a digital signing key and sign data/transaction with it. It has nothing to do with trust.

<p>Let’s think about what blockchain does and what a certification authority (CA) does.</p><p>Blockchain is basically a chain of signatures. You create a digital signing key and sign data/transaction with it. Each new signature is over 2 items:</p><ol><li>the data/transaction you want to sign - it could be a string with a “public key” and “name”; and</li><li>the previous signature you created.</li></ol><p>CA verifies that a certain “name” belongs to YOU, that you own a “public key”, and binds the “name” and “public key” together with a digital signature. YOU can be a domain name, email address, an organisation, a physical person with a postal address, and so on. CA will use any of a number of methods to verify that the “name” is YOU. The signature at the end is the easy part.</p><p>So Blockchain can create a signature, but that is hardly enough to replace CA. But let’s say, we want use Blockchain. The first question would be - who verifies that the “name” is you, who will be responsible for the correctness, how you compare independent proves, if you expect more than 1.</p><p>On a side-note, good CAs will sign all their operational log as a “blockchain”, i.e., linked together. :)</p>

Publication Date: 2019-06-14 13:06:00

Is a password of 20 characters strong enough to use?

It could be but it may not, it depends on how random those 20 characters are. Let me demonstrate the thought with 2 common attacks on passwords.

<p>It could be but it may not, it depends on how random those 20 characters are. Let me demonstrate the thought with 2 common attacks on passwords. These attacks are:</p><ol><li>dictionary - using dictionaries of passwords someone else used before or words from “normal” dictionaries, including concatenations of 2 or more words;</li><li>brute-force - trying all possible combination of characters (letters, numbers, special characters), possibly using templates, e.g., first letter is capital, last is number, lower-case in the middle.</li></ol><p>So if you use 2–3 common words to get 20 characters’ password, then it will be weak.</p><p>If your password is random and not in any of the dictionaries (attack no 1 is impossible), it has to be long enough to withstand brute-force attacks.</p><p>In this case, a 20 characters’ long password made up from 70 different symbols (lower case, upper case, digits, special characters) is as strong as today’s encryption keys. Which means, it is “cryptographically secure” and it doesn’t make sense to go any further.</p><p>If you think Google represents industry standards, then its Google Authenticator uses secrets of 80 bits = 13 characters passwords as defined above. These secrets are used to compute one-time passwords.</p>

Publication Date: 2019-06-14 13:01:00

What could be done if all current Encryption could be broken and cracked?

If all current encryption were suddenly broken, that would be the end of it for encryption as we know it. With one exception - one-time pad.

<p>If all current encryption were suddenly broken, that would be the end of it for encryption as we know it. With one exception - one-time pad. One-time pad is a provably secure encryption that can’t be broken, but it has practical difficulties - it requires keys as long as the data.</p><p>There are, however, alternatives to encryption and there is also a saying “If you think encryption will solve your problem, you don’t know what is your problem.”.</p><p>If you want to “crack” encrypted data, you need to get the encrypted data first. The most likely defence would in this case be protection of the communication channels - whether by splitting data between 2 or more channels, making access to these communication channels hard, or hiding the fact that there is any data present (e.g., by mixing it up with random noise).</p><p>Practically - you can’t do much. Current encryption algorithms are hard-coded to critical business applications and it would be impossible to change much in less than 6–12 months.</p><p>We may be forced to think which data is sensitive and important and which data we actually don’t have to send or store in the first place. This is another great way of protecting us from getting hacked.</p>

Publication Date: 2019-06-14 12:57:00

What Is Encryption Domain

Encryption domain is simply a set of computers or other computing devices (or even people :) ) who share encryption key(s) allowing them to trust each other.

<p>Encryption domain is simply a set of computers or other computing devices (or even people :) ) who share encryption key(s) allowing them to trust each other.</p><p>It can be a master authentication key which can easily verify identities of entities within the encryption domain. Or it can be an encryption key, which allows access to encrypted data or communication.</p><p>The point of encryption domains is to create an environment where all entities within an encryption domain can automatically verify each other or share access to and create encrypted assets which can be accessed with the knowledge of “domain encryption key”.</p>

Publication Date: 2019-06-14 12:54:00

What is the SHA-256 fingerprint?

SHA-256 fingerprint is a digital fingerprint we use to compare two documents or to check if a document has been changed.

<p>It is a digital fingerprint we use to compare two documents or to check if a document has been changed.</p><p>It has a fixed length of 64 bytes (or characters, if you want), which encode 256 bits, each bit is either 0 or 1. Once calculated, it is unique for the data or file for which it has been created. While it is relatively short, it is practically impossible to compute any other document, which would have the same fingerprint.</p><p>The main properties of digital fingerprints, including SHA-256 are:</p><ol><li>It’s short - it is always 256 bits regardless of whether the original data is 100 bytes or 100 terabytes.</li><li>It’s impossible to compute a different data which would have the same fingerprint.</li><li>It’s impossible to compute the original data from the fingerprint.</li></ol><p>What it DOES NOT do - it doesn’t necessarily protect against discovering the original data, if the original data comes from a sufficiently small set. Attackers can simply try all possible data values and find a match. Let's take ZIP codes as an example. There are less than 100,000 5-digit zip codes in the USA and 1,000,000,000 zip+4 codes. It's trivial for your laptop to calculated SHA-256 fingerprints of all of them and compare them to the one fingerprint you want to "reverse". This approach is used to create "rainbow tables" - fingerprint tables of all possible values - used to crack our passwords.</p><p>From practical point of view:</p><p>- It DOES “hide” the original data (with the caveat above).</p><p>- It simplifies data search - it can speed up database queries when they are done with fingerprints, rather than the data itself.</p><p>- It is fast to calculate.</p><p>- If it’s too long for you, you can use only part of the fingerprint and it still works (too much detail possibly, but beware of the birthday paradox if you don’t want to end up with collisions -&nbsp;<a href="https://en.wikipedia.org/wiki/Birthday_problem" target="_blank" style="color: rgb(43, 109, 173);">Birthday problem - Wikipedia</a>).</p><p>The name also denotes the function used to calculated it (SHA-256), which is one of the family of functions called SHA-2 and which includes SHA-224, SHA-256, SHA-384 and SHA-512, where the number indicates the size of the fingerprints.</p>

Publication Date: 2019-06-14 12:41:00

What is certificate pinning

Some people argue that certificate pinning is a must to protect against sophisticated attacks. Some will say that it's pain in the bottom. But what is it actually?

<p>Some people argue that certificate pinning is a must to protect against sophisticated attacks. Some will say that it is a pain in the bottom. But what is it actually?</p><p>Certificate pinning is a mechanism that introduces "direct trust" between your web browser and a web server. When the web server (e.g., quora.com) provides a "pinning flag", your web browser will remember it and will warn you when you try to connect to the quora.com server again and it shows a warning if it detects a configuration change (i.e., someone attacks you or someone made a configuration error).</p><p>The usual verification of HTTPS is using standard X.509, which defines certificate verification via proxy, where the proxy is a “trusted authority”, or a CA. We, as users, don’t care which certificate is used so long as the trusted authority confirms it’s a good one. And as long as the trusted authority is trusted by our web browsers.</p><p>Pinning means that you only trust the certificate you have seen before. You may use the proxy for the first validation, or you can just say whatever it is, I trust it.</p><p>When you talk to the same server again, you only trust it if it uses the same certificate. If it’s a different one, it will raise an alarm even if the proxy says it’s a good one.</p><p>In a way, the concept of certificate pinning is direct trust, just like in PGP (if you’re familiar with this system).</p>

Publication Date: 2019-06-07 07:53:00

Reliability of Let's Encrypt

I have analyzed reliability of Let’s Encrypt using their own data in Spring 2018.

<p>It’s a good question especially after a recent&nbsp;<a href="https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922" target="_blank" style="color: rgb(43, 109, 173);">downtime of LE</a>&nbsp;that lasted more than a day, with 16 hours of the service basically unavailable. This is quite a serious outage, which will probably put LE behind most of other certificate provides as it makes it uptime just 99.8% on its own for this year.</p><p>As LE assumes that renewals are automated, you should never assume that LE services will be always available and design your own production automation accordingly.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Let's Encrypt planned updates and their actual duration." src="/storage/wink/images/bTp1ljxHT4oYcr6XKTB3GuGh5D7BQPEiFUGDQm3x.png"><p>Let's Encrypt planned updates and their actual duration.</p></div><p>Having said that, I don’t believe there is a real possibility of an outage, which would last more than a week so in terms of issuance and certificate renewals LE is likely to remain reliable if you plan and renew according to recommended timelines.</p><p>Other than that, you should consider operational limits of LE. I have written up&nbsp;<a href="https://keychest.net/content/letsencrypt_numbers_to_know" target="_blank" style="color: rgb(43, 109, 173);">many of them into one blog post here</a>.</p><p>You may also be interested in assurance in terms of potential damage caused by incidents. I haven’t found any authoritative reference for any such assurance yet.</p><p>I have analyzed reliability of Let’s Encrypt using their own data in Spring 2018. </p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Duration of &quot;full&quot; disruptions per month with incident detail at the bottom." src="/storage/wink/images/071NXyAp95YZ5uEw8iKcTsZHLAPIbzA6QcTsyVxR.png"><p>Duration of "full" disruptions per month with incident detail at the bottom.</p></div><p>I used a couple of charts above and the write-up is at <a href="https://dan.enigmabridge.com/lets-encrypt-uptime-is-99-9%E2%80%8A-%E2%80%8Aor-98-8-without-defects-in-2017/" target="_blank" style="color: rgb(43, 109, 173);">Let’s Encrypt uptime is 99.9% — or 98.8% without defects in 2017</a>. It shows that it was fully up and running only for 98.8% of time in 2017. Some disruptions were “partial” so only a subset of users would experience them.</p><p>Another important aspect are changes to the protocol and its implementation. Many users experienced problem in Q3 as LE set IPv6 as the primary protocol. It was used whenever it detected existence of an IPv6 address, regardless of whether it actually worked.</p><p>It certainly makes sense to deploy an external end-to-end monitoring to detect any potential issues early on - something like our <a href="https://keychest.net" target="_blank">KeyChest service</a> .</p>

Publication Date: 2019-06-07 07:41:00

What are disadvantages of Let's Encrypt

Letsencrypt is now installed on more than 50% of all webservers. This is mostly thanks to its adoption by many web hosting providers. We can also see it starts being used by large companies and enterprises. But what are the downsides?

<p>Letsencrypt is now installed on more than 50% of all webservers. This is mostly thanks to its adoption by many web hosting providers. We can also see it starts being used by large companies and enterprises. But what are the downsides?</p><p>First of all - certificates' (including Let's Encrypt certificates) main task is to prove the authenticity of their owner, e.g., a web server. There is no difference between Let’s Encrypt and any other certificate your browser can verify (DigiCert, COMODO, Entrust, etc), and all browsers can now verify Let’s Encrypt certificates.</p><h3>Rate Limits</h3><p>When we look at limitations of Let's Encrypt, they are mostly operational. There is one big disadvantage of Let’s Encrypt - rate limits. These restrict the number of operations you can do per second, hour, week, depending on the type of requests. The limits are most severe for the number of certificates you can issue per “registered domain”, e.g.&nbsp;keychest.net. <a href="https://keychest.net/content/letsencrypt_numbers_to_know" target="_blank" style="color: rgb(43, 109, 173);">I have described most of those limits here</a>.</p><h3>New management approach</h3><p>Further, when using a Let’s Encrypt certificate, there are significant operational differences, i.e., how you manage such a certificate on your server.</p><p>Let’s Encrypt uses a set of new protocols for automated certificate management. There are two important effects of that:</p><ol><li>The process of issuing a certificate is different from most other CAs, which require manual steps, notably proving that you are the owner of a given server.</li><li>The same process is designed to work fully automatically. Let’s Encrypt is about automation to keep the certificate issuance costs low. There’s always a question how much you need to automate something you do once a year or maybe once every two years, this may be one of the reasons why Let’s Encrypt certificates are valid only 90 days.</li></ol><p>As a result, you have to renew your certificates four times, but more likely 6 times a year (due to time overlap), but you can automate it, if you have the skills and/or support. I would also recommend&nbsp;<a href="https://community.letsencrypt.org/t/monitoring-the-state-of-certificates-cont/37764" target="_blank" style="color: rgb(43, 109, 173);">monitoring</a>&nbsp;that your automation works. (I have been active in this area so you can try our service&nbsp;<a href="https://keychest.net/" target="_blank" style="color: rgb(43, 109, 173);">KeyChest</a>, which is free for 500 domains and personal use.)</p><h3>Reliability (2017)</h3><p>I have also recently looked into the reliability of Let’s Encrypt certificate issuance and described some of the results in my blog <a href="https://dan.enigmabridge.com/lets-encrypt-uptime-is-99-9%E2%80%8A-%E2%80%8Aor-98-8-without-defects-in-2017/" target="_blank" style="color: rgb(43, 109, 173);">Let’s Encrypt uptime is 99.9% — or 98.8% without defects in 2017</a>. It’s actually quite good for a completely new system, but much worse than commercial CAs. I came up with 2 numbers: 98.0% and 99.9%, and the real truth is somewhere between them for vast majority of users. 99.9% is when Let’s Encrypt was up for at least some of its users, 98.0% when it worked flawlessly.</p><h3><strong>Reliability (2019)</strong></h3><p>I have recently <a href="https://keychest.net/stories/lets-encrypt-uptime-2-years-on" target="_blank" style="color: rgb(43, 109, 173); background-color: rgb(255, 255, 255);">revisited the reliability</a> of Let's Encrypt with data covering December 2018 to November 2019. I received an interesting reaction at the LE community forum. The initial response was that I have over-reported downtimes but my results were eventually accepted (after some double-checking).</p><p>The bottom line is that it hasn’t got much better over the last two years. Despite the total number of disruptions being lower and planned upgrades becoming a routine business-as-usual operation.</p><p>The most important figures - the uptime are similar to 2017.</p><ul><li><strong>Uptime with full disruptions only: 2019 - </strong><strong style="color: rgb(16, 16, 16);">99.92%, 2017 - 99.86% </strong></li><li><strong style="color: rgb(16, 16, 16);">Uptime when partial disruptions added: 2019 - 96.4%, 2017 - 98%</strong></li></ul><p>The 2019 operation includes<strong> two short disruptions (&lt; 10 mins) of their OCSP service</strong>, which has immediate impact when users visit new web servers as the certificate validity can’ be confirmed.</p><h3>Practical / operational consideration</h3><p>From operational point of view, there is a number of differences from commercial certificates that may or may not be important.</p><p><strong>The type of certificates</strong></p><p>Till recently, I would say this is not too important as all types are accepted by web browsers. However, with the adoption of <a href="https://support.dnsimple.com/articles/caa-record/" target="_blank">DNS CAA checks and notifications</a>, the "more expensive" certificates can provide a better protection of certificate buyers.</p><ul><li>Let’s Encrypt offers only certificates with the lowest level of validations as this can be automated. These are called Domain Validated SSL Certificate.</li><li>Other Certificate Authorities offer certificates with more through validation: organization validation (OV), or Extended Validation (EV). These verify requests for certificates more thoroughly</li></ul><p><strong>Validity of certificates</strong></p><ul><li>Let’s Encrypt allows only 90 days validate where you need to reissue a certificate on every 90 days period.</li><li>Other Certificate Authorities offers 1 to 3 years validity period for any type of certificate.</li></ul><p><strong>Missing CRL in Let's Encrypt certificates</strong></p><ul><li>Let's Encrypt doesn't have certificate revocation lists (CRLs). It only offers real-time validation of certificates with the <a href="https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol" target="_blank">OCSP protocol</a>.</li><li>Other Certificate Authorities implement CRLs, which makes validation of certificates more reliable. I.e., short downtimes of Let's Encrypt OCSP servers mentioned in the uptime analysis would mean that Let's Encrypt websites can't be access during those periods.</li></ul><p><strong>Service for Certificates</strong></p><ul><li>Let's Encrypt doesn't offer any service that would help you manage your certificates and their expiry.</li><li>Other Certificate Authorities offer a range of services to improve overall security of your websites but also to manage your certificates.</li></ul><p><em>Note: This is something where </em><a href="https://keychest.net" target="_blank"><em>KeyChest</em></a><em> significantly helps to establish level playing field for Let's Encrypt.</em></p><h3>Phishing Problem</h3><p>This is more a problem of a perception and expectations. SSL certificates are not a silver bullet solution. It only provides a particular function, i.e., encryption of traffic between your browser and a web server.</p><p><span style="color: rgb(51, 51, 51);">Let’s Encrypt has naturally become a go-to CA for phishers as it fully automates the issuance process and doesn't ask any questions.. Let’s Encrypt also argues that it is not its job to stop malicious sites from using its certificates. While it is factually correct, it goes against expectations that many people have. Expectations that helped Let's Encrypt become successful and expectations that lead to a massive increase of the HTTPS use.</span></p><p><span style="color: rgb(51, 51, 51);">This meant that phishers and malware distributors were free to use Let’s Encrypt without any risk of being banned or having their certificate revoked &amp; one of the prominent example is that&nbsp;</span><a href="https://www.thesslstore.com/blog/lets-encrypt-phishing/" target="_blank" style="color: rgb(43, 109, 173);">over 14,000 SSL Certificates issued to PayPal phishing sites</a><span style="color: rgb(51, 51, 51);">.</span></p><h3>"Color" of padlock</h3><p>As a side note, and another aspect of the point 1 above. There is a special type of certificates - so called Extended Validation certificates, or EV certificates. When a server presents an EV certificate, browsers tend to show the company name, rather than a web address. You can see the difference below - a Let’s Encrypt certificate (top) and an EV certificate (bottom).</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Domain validated certificate will only show the domain name." src="/storage/wink/images/eAFJkLmTjFBA9f8uioMnzl8U3RjZlDntXSxMKIRo.png"><p>Domain validated certificate will only show the domain name.</p></div><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Extended validation (EV) certificate will show the company name." src="/storage/wink/images/DOStMD4PBhEl8gpAZ8mbbk46Nc3Rj8a5RoV6kOda.png"><p>Extended validation (EV) certificate will show the company name.</p></div><p><br></p><p><br></p>

Publication Date: 2019-06-07 07:24:00

KeyChest Update - June 2019

Having spent quite a few months working on the "invisible" code powering KeyChest, we have added two new reports - phishing threat and identity reports. But that is not all, we will finally add agents for monitoring internal networks.

<p>Having spent quite a few months working on the "invisible" code powering KeyChest, we have added two new reports - phishing threat and identity reports. But that is not all, we will finally add agents for monitoring internal networks.</p><hr><p>KeyChest is still a bootstrapping company powered by my time and savings. That means that there are too few heads for too many hats - as in any start-up - from marketing (or testing marketing options), looking for customers as we are aiming at B2B business model, answering your questions and request (and we are very grateful for any feedback you send our way) ... to adding new KeyChest features. This time I will focus on the technology.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="An overall report of phishing threat for all registered domains in an account." src="/storage/wink/images/P7cc9XYfssrbKyfzLuK8VGstlcuhAf1T5GstHld6.png"><p>An overall report of phishing threat for all registered domains in an account.</p></div><p>I have added two new reports to the KeyChest dashboard - identity report and phishing threat report. You can see the phishing report above and this is what happens behind the scenes.</p><h2>Phishing Threat Report</h2><ol><li>we use a customized <a href="https://github.com/elceef/dnstwist" target="_blank">dnstwist module</a> to generate variants of domain names. We continue processing those in batches of 500.</li><li>Each batch of up to 500 is checked against our global lookup table of all issued certificates and we keep domains for which we find at least one certificate - it doesn't have to be valid at the moment.</li><li>The domains left are then checked for valid DNS records, MX record (i.e., email server exists), and A/AAAA records - i.e., hostnames one can use to host web sites.</li><li>All the distilled information is stored in the KeyChest database ready for reporting.</li><li>We try to structure the reports to be a little easier to read. We categorize each of the found "potential threat" as High, Avg, or Low risk. We will probably revise the criteria but at the moment, the High Risk are all domains created as Homoglyph (this includes use of international characters that look similar to ASCII ones). Medium Risk are domains with a valid certificate, email server and a "web hosting" domain name.</li></ol><p>If you decide to invest $10/month or more, you will also be able to see details of all domains, like this.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Detail of phishing threats" src="/storage/wink/images/KR98yUOrQoAERrbAK0FeVoXrQPVtYIEAY0XSda9W.png"><p>Detail of phishing threats</p></div><h2>Identity Report</h2><p>Identity report is a new report that focuses purely on keys. It can therefore use our global database of certificate to its maximum effect. Keys (and certificates) are group by their names and the table shows the date of the first certificate as well as the last update and expiration. </p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Detail of a digital identity history - the buttons on the right lead to detail cards." src="/storage/wink/images/90Xgc3d6YK4sNgeEcGDQOjQKXXcRSTLAXTPLpWO8.png"><p>Detail of a digital identity history - the buttons on the right lead to detail cards.</p></div><p><br></p>

Publication Date: 2019-06-05 21:12:00

Is Biometric authentication on smartphones secure?

No answer is universally correct but here’s two use-cases so you can pick which is more appropriate for you - PIN or fingerprint.

<p>No answer is universally correct but here’s two use-cases so you can pick which is more appropriate for you.</p><ol><li>PIN:</li><li class="ql-indent-1">you’re on the train and there are baddies looking for victims. It’s fairly easy for them to eavesdrop your PIN and then steal your phone, get in and sell your personal data &amp; passwords.</li><li class="ql-indent-1">On the other hand - if FBI needs to get a PIN to a locked phone, they may call an Israeli high-security start-up, pay tens of thousands of dollars to unlock it.</li><li>Fingerprint</li><li class="ql-indent-1">back on the train - it would be pretty hard and risky for low-skilled baddies to unlock your phone without using&nbsp;<a href="https://www.ccc.de/en/updates/2013/ccc-breaks-apple-touchid" target="_blank" style="color: rgb(43, 109, 173);">some hackers</a>&nbsp;to get a printout of your fingerprint, invert it, create a latex film …</li><li class="ql-indent-1">FBI will have no problem whatsoever, to get your fingerprint, create a latex copy and unlock the phone.</li></ol><p>PIN attacks have zero initial costs and can be instant. Fingerprint attacks will costs hundreds of dollars and some time. So the question is what is the pay-off and what the bad guys are after. :)</p><p><br></p>

Publication Date: 2019-06-01 20:21:00

What are the impacts of cryptography in IT?

Let me assume your question is about the impact on IT users. If you want to think about cryptography as a mechanism to achieve a business / user value, you can see it as a means to extend “trusted environment”

<p>Let me assume your question is about the impact on IT users. If you want to think about cryptography as a mechanism to achieve a business / user value, you can see it as a means to extend “trusted environment”.</p><p>If you trust computers in your office, you basically assume there’s a trusted domain or zone.</p><p>It is important there’s such a trusted zone as cryptography always has one or more endpoints where you can securely use your encryption keys. Breaching this assumption compromises cryptographic keys and invalidates any cryptographic protection. Your trusted zone can be your mobile phone, office PCs, smartcard in your pocket, …</p><p>Cryptography either:</p><ol><li>extends your trusted zone - you encrypt data in your trusted zone and the you can send / store / process it in untrusted environment. The data is protected by your encryption</li><li>connects two or more trusted zones - you encrypt/decrypt data in one or more of the trusted zones and when the data is between these trusted zones, it’s again protected by encryption.</li></ol><p>The protection you get from cryptography can be confidentiality (data is visible only in trusted zone(s) ), integrity (any change of data outside trusted zones can be always detected), authenticity (data that was outside trusted zone can always be linked back to its source), etc</p>

Publication Date: 2019-05-26 20:18:00

Are passwords really more secure if they must be so complex that I can't remember them and write them down?

Let me start with a question - why do banks believe that 4 digit PIN on your credit card is secure when a random guess have a chance of 1 in 10,000 to be correct. Does 3496 ...

<p>Let me start with a question - why do banks believe that 4 digit PIN on your credit card is secure when a random guess have a chance of 1 in 10,000 to be correct. Does 3496 sound that much more secure than “password123” ?</p><p><em>Note: I did an experiment on my WP blog back in 2013 with some cool data -&nbsp;</em><a href="https://dan.enigmabridge.com/password-attacks-a-small-server-experiment/" target="_blank" style="color: rgb(43, 109, 173);"><em>Password Attacks - A Small Server Experiment - Magic of Security</em></a><em>&nbsp;- at the bottom you can see the most often tested passwords.</em></p><p>Back to PINs v passwords - the reason why PINs are cool is that the bank controls and counts every try of PIN entry. Because your card is in your pocket and you can only test the PIN when you plug it somewhere, bank can block the PIN if you try a wrong one 3 times in a row. Why this doesn’t work with web passwords?</p><ol><li>your account is online so anyone can try to guess your password whenever they want (if they know your username) - blocking the password after 3 tries would only result in all of us being locked-out of our accounts in days (hmm - it would be interesting to find out how long it could take :) )</li><li>companies running websites are pretty bad in implementing any decent control of password use. Hence password protection like PBKDF2, which disproportionately hits users with slow computers. Instead of doing a proper job on the web server side, prevent suspicious behaviour, locking out botnets, implement counters (per user and global) to detect potential problems and attacks.</li></ol><p>If you make your password really hard to remember, it’s probably more secure because of how web services treat it. When there’s a big password incident it’s always due to insecurity of servers, not users.</p><p>My advice would be:</p><ol><li>if you create an account on a website that you don’t really trust, or where you leave personal data you don’t see that sensitive, use a password that is different from websites that you really care about, e.g., your online banking.</li><li>the most important and most secure password should be used to login to your email - that is THE MOST important password of all as almost any other account can be unlocked using your email.</li></ol><p><br></p>

Publication Date: 2019-05-26 20:15:00

Is there a way to generate a self-signed EV SSL (X.509) certificate?

Technically, all you need is to add correct extensions to your certificate, which will identify it as an EV certificate.

<p>Technically, all you need is to add correct extensions to your certificate, which will identify it as an EV certificate. CA/Browser forum defined one in&nbsp;<a href="https://cabforum.org/wp-content/uploads/EV-V1_6_2.pdf" target="_blank" style="color: rgb(43, 109, 173);">https://cabforum.org/wp-content/...</a>&nbsp;(section 9.3.2).</p><p>A list of extensions used by particular venders is here:&nbsp;<a href="https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification" target="_blank" style="color: rgb(43, 109, 173);">Extended Validation Certificate - Wikipedia</a></p><p>I guess you can argue that you extensively validated your certificate, but it will be hard to persuade others so. :)</p>

Publication Date: 2019-05-25 20:24:00

Will we ever stop using passwords for data protection?

I have been closely following authentication methods over the last 10 years or so and here’s a short list of my thoughts in 9 points.

<p>I have been closely following authentication methods over the last 10 years or so and here’s a short list of my thoughts:</p><ol><li>people have been talking about the end of passwords for decades. While they have drawbacks (some are weak, they don’t change for a long time, some people can’t use them - dyslexia) they are the simplest to use, simplest to implement and cross platform authentication mechanism. They will never disappear.</li><li>Your email password has become the single MOST IMPORTANT password you have as almost all other passwords can be reset via email!</li><li>It’s not that difficult to implement server-side password systems to prevent large scale incidents. However, the cost of implementing them properly is still higher than risk X cost of attacks. If someone like Paypal looked at the cost of incidents (unauthorized transfers due to stolen passwords) and compared that with the cost to the business (making authentication harder + cost of development). The result - passwords would be good.</li><li>If password-based attacks become a problem, they are relatively easy to augment with additional restrictions (permanent or temporary).</li><li>For a while there was a really fragmented market of alternatives - visual passwords, join-the-dots, select a set of images, hardware dongles, biometric-based methods and it wasn’t clear who will be the winner. I think this stage is over and the winner is an approach that uses our personal devices to help us (from laptops to smart phones).</li><li>Passwords are disappearing in a sense that you may not see them that much - Windows, OSX, browsers, smartphones automatically log you in, iOS now offers auto-fill when it sees a password box and you just need to press your thumb on the start button. The user-side password handling is now implemented in platforms and custom applications (e.g., 1password) become unnecessary.</li><li>Big companies are not that much interested in attacks on particular users. Their concern are easy-to-scale attacks that could hit millions of users in a short time. Linking you “person” to your device that can provide strong authentication fits this bill.</li><li>The approach that replaces authentication of yourself with authentication of your personal device prevents scalable attacks. However if someone steals your smartphone, you’re doomed.</li><li>If you want to protect yourself, you need to do something for it. Think about what you can lose, how easy would it be for someone to steal / infect / take-over your smartphone / laptop and use it to access your data and access privileges.</li></ol><p><br></p>

Publication Date: 2019-05-25 15:47:00

What would happen to the world within one year after someone published an algorithm that could break the RSA encryption instantly?

It is not so hypothetical question as ROCA attack gave as a taste of that in Autumn 2017. A lot of stuff was happening behind the scenes ...

<p>It is not so hypothetical question as <a href="https://keychest.net/roca#/" target="_blank" style="color: rgb(43, 109, 173);">ROCA attack</a> gave as a taste of that in Autumn 2017. A lot of stuff was happening behind the scenes and I believe there are many enterprises are yet to realise some important vulnerabilities (e.g., encrypted documents without proper protection).</p><p>What happened then was that affected parties were notified some 9 months before the attack publication. Interestingly, the publication date was fixed mainly because it was to be presented at a conference so companies like HP, Microsoft, Google couldn’t make authors push the date of the publication. Although they did it successfully for pre-release notification, which made life harder for companies “further down the food chain”.</p><p>Anything on that scale, assuming it was discovered by law-abiding persons/companies, the “management” of the knowledge would likely be taken over by security agencies or a wide consortium of enterprises or both.</p><p>Now, let’s assume the inventors are not happy with keeping it secret and simply publish it - everything is a pure speculation :)</p><ol><li>day 1 - authors will try to find publishing outlets and start getting visibility</li><li>day 2 - first injunctions and gagging orders are issued, news spreads via social networks</li><li>day 7–14 - it will be taken seriously enough for people start verifying the discovery</li><li>day 14 - security patches for web browsers and applications that will extend RSA signatures with timestamps, peer-to-peer verifications, etc</li><li>day 21 - corporations start realising that that the biggest problem are document stores (not transactions)</li><li>day 30 - there are tools out there - closed and open-source</li><li>day 90 - many applications replace RSA with peer-to-peer symmetric encryption</li><li>1–2 years on - RSA replaced with a new algorithm</li></ol>

Publication Date: 2019-05-20 20:09:00

Why is the public only concerned with Facebook selling data and not ISPs selling data?

This will be controversial but I think the reason why Facebook suddenly got to front-pages is an alleged use of its data for Trump’s campaign (and other political purposes). I’ve been a post-doc at Cambridge Uni in 2007–08 and I remember a lot of activity around Face...

<p>This will be controversial but I think the reason why Facebook suddenly got to front-pages is an alleged use of its data for Trump’s campaign (and other political purposes). I’ve been a post-doc at Cambridge Uni in 2007–08 and I remember a lot of activity around Facebook as its data was easy to collect (in that instance the research was about social networks, trust, … one particular research area was to produce models of social connectivity for simulation of security threat models in large networks). There has been loads of research papers using its data and no-one was bothered then nor anytime up to 2017.</p><p>Also, I think that ISPs probably did the “expectation management” a bit better and have been quite open where they stand in terms of the “personal data and free speech” context.</p><p>(One thing I’m still not quite sure about is whether the data sold by Facebook would be subject of e.g., the new European GDPR regulation protecting personal data. The thing is that the data in question is unlikely to identify particular users - their names, email addresses, real addresses, and so on. )</p>

Publication Date: 2019-05-19 20:32:00

I always get SSL errors on a WiFi. What's the reason behind this?

WiFi routers should pass any traffic transparently unless its configuration is really messed up. If we ignore a configuration problem and you see any SSL errors, the only possible reason I can think of is that there is a “proxy” between your computer and Google...

<p>WiFi routers should pass any traffic transparently unless its configuration is really messed up.</p><p>If we ignore a configuration problem and you see any SSL errors, the only possible reason I can think of is that there is a “proxy” between your computer and Google servers, which decrypts and then re-encrypts your data for “inspection”. It basically means that the secure channel from Google is terminated on a server that your computer talks to without you realizing it.</p><p>The chances are that your router is partially set up as such a proxy so that it causes SSL errors. Corporations often use such proxy servers to monitor use of social media from office computers to prevent leakage of confidential information.</p>

Publication Date: 2019-05-19 20:27:00

Publication Date: 2019-05-19 20:13:00

What are online security certificates, SSL, HTTPS and how do they work?

If you’re interested in technical details, the best really is to read relevant standards. However, it’s relatively easy to give you a good idea of what they are.

<p>If you’re interested in technical details, the best really is to read relevant standards. However, it’s relatively easy to give you a good idea of what they are.</p><p>All these acronyms and other (DER, BER, PEM, x509, …. ) are for the same thing. That is a digital “document” with the following content in simple terms:</p><ul><li>reference (ID)</li><li>owner</li><li>issuer</li><li>effective date</li><li>expiry date</li><li>owner’s encryption key</li><li>&lt;loads of caveats and technical jargon&gt;</li><li>issuer’s signature</li></ul><p>The purpose of the certificate is to create a link, verified by the issuer, between:</p><ol><li>owner; and</li><li>owner’s encryption key</li></ol><p>Just like with any other document you need to trust the authority of the “issuer” of the certificate. You can issue certificates for your friends (so long as they trust you) or you need to pay someone who is trusted by Google, Microsoft, Red Hat, Linux distribution managers,…</p><p>These companies add “trusted issuers” into computers and browsers they sell / distribute. So if you reach a website, e.g.,<a href="https://keychest.net/" target="_blank" style="color: rgb(43, 109, 173);">https://keychest.net</a>&nbsp;, and it provides a certificate issued by one of the “trusted issuers”, your browser will show a green padlock.</p><p>What exactly the “green padlock” mean is a more complicated question. :)</p>

Publication Date: 2019-05-19 20:05:00