Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Compromised certificates and certificate revocation. Status ?


  • Please log in to reply
14 replies to this topic

#1 palerider2

palerider2

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 20 September 2016 - 11:14 PM

In Apr 2014 the world had the Heartbleed event. Definitely a low-point for internet security.
 
Since then over 100,000 website certificates have been revoked because the site owners either knew the certificate was compromised, suspected the same or simply couldn't take the chance.
 
Stats for daily revocations are here : isc.sans.edu/crls.html
That site notes that on 16th Apr 2014 alone, more than 30,000 certificates were revoked !
 
Using the site it's possible to create a graph which shows the cumulative number of revoked certificates (as per grc.com). However, that doesn't mean that Certificate Revocation Lists (CRLs) keep growing in size.
 
Certificates which have reached their natural end of life do not need to appear in CRLs because browsers detect these automatically. So the old certificates can be culled from CRLs, creating a downward force on CRL size. On the other hand, somewhere between 200 and 500 certificates are still revoked daily (it seems to be the natural rate, at present - Sep 2016).
 
I wondered if there was a graph (or other data) which shows the total number of certificates that are listed in all of the CRLs combined, at any given point in time over the last 3 years. Is such a graph available to view ?
 
Just putting Heartbleed in perspective, any certificate that had a maximum validity period of 2 years and was valid in April 2014 would have reached its end-of-life date by May 2016. So, in large part, the legacy of Heartbleed is behind us.
 
But then we have longer-lasting certificates, including intermediate certificates. And we also have code-signing certificates.
 


BC AdBot (Login to Remove)

 


#2 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 23 November 2016 - 11:06 PM

Regarding the isc.sans.edu site, I noticed that the number of daily revocations has been following a fairly stable pattern for quite a few months now (other than the occasional large peak).
 
However, I noticed that since 20th November (the last 4 days) the daily revocations have been lower. Significantly lower.
 
Instead of about 600 daily revocations (a typical number for Mon-Fri) there have been about 40 and 60 for Mon and Tues this week.
 
I wondered if any user of the BC site had a comment about that. Thanks in advance if you do !
 
Here's the full URL
 
First, have a look at the 4 most recent data points. Then change the Start Date to (say) Jun 2016. Don't forget to click 'Update'.
 
Note how the pattern is very well established and that the data for the last 4 days breaks that pattern.


#3 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 25 November 2016 - 10:02 PM

No particular mystery - it looks as though it takes about 4 days for all of the data to be present in the graph.
 
Based on the established pattern, I estimate that about 4100 certificates are being revoked weekly. However, that isn't necessarily an indication of a huge ongoing security issue. This is because not all certificates are revoked due to key compromise. So I'd like to see the Reason data.
 
I started looking at a CRL in order to determine the layout and had some success with that. However the reason for revocation did not seem to be present.
 
Below is a CRL that I downloaded - it's a small one, just 1 KiB. It's from the same CA whose CRL I looked at more closely and presumably it has the same layout. It uses an ASN.1 format.
 
crl.comodoca.com/COMODOECCDomainValidationSecureServerCA2.crl
 
In this file :
the first entry commences at offset 00CC and it is 0x22 bytes long plus 2 for the length field itself.
the second entry commences at offset 00F0 and it is 0x21 bytes long plus 2.
the last entry commences at offset 0113 and it is 0x22 bytes long plus 2.
 
Where the entries are 1 byte longer, this seems to be because the 16-byte serial number is preceded by 00.
 
My objective with this mini investigation would be to gain an understanding of how many certificates are being revoked (say) weekly due to key compromise and then use that to identify any underlying trend.
 
For all I know, there may not be many revocations resulting from key compromise at the present time. Other reasons will exist. It did occur to me that some web sites will have become customers of Lets Encrypt even though the site already had a certificate from elsewhere that was still time-valid. In those cases it's possible that the old certificate would then be revoked for Reason 4 - Superceded.
 
I assume I have missed the Reason data and that it *is* actually present in all CRLs, even though the layout may change from one CA to another.
 
The layout that I presently have (from a larger CRL) :
65BB6      30 21                 seq. overall len = 33d
                02 10                 int. len = 16d
65BBA     5C 92 E1 ... 8A 49 E2          serial number
65BCA     17 0D                time? len = 13d
65BCC     '161120'            date: 20th Nov 2016
65BD2     '063139'            time: 6:31:39 am
65BD8     'Z' 

Edited by palerider2, 25 November 2016 - 10:04 PM.


#4 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 01 December 2016 - 12:15 AM

First, just an update on that last post: it can take more than a week for all of the data to be collected by Sans and then be presented in the graph. CRLs are generally updated every few days, which is where the time lag comes from.
 
Further research has answered some of the questions raised previously. A lot of useful information came from the RFC 5280 document, which describes the structure of Certificate Revocation Lists (CRLs). 
 
1. Entries in CRLs don't always include a reason for revocation. This is why I couldn't find the reason data in the first two CRLs that I examined. It appears to be the policy of some CAs not to include the Reason data and this may seem like a departure from RFC 5280. However the Reason data is officially termed "non-critical".
(The exclusion of Reason data may seem strange but it's definitely the case, some of the time. I'm sure that, in the current climate, it's absence is considered to be a pain by browser suppliers !  To be fair, however, browser suppliers are now using CRLs for a purpose that's slightly different than the original intention. Nevertheless, it would be good if CAs recognised this. If the RFC itself is ever modified I would suggest that the Reason data be reclassified as critical.)
 
2. Serial numbers are not always 16 bytes long. CAs can make these fields any length that they like.
 
3. When there is an extra 00 at the front of the certificate serial number in the CRL it's because the first byte of the regular serial number has a value of 0x80 or greater. In other words the most significant bit of the first byte is SET. To a program this could indicate a negative number and the spec says that the serial number should always appear as a positive integer. Adding the leading 00 removes the 'doubt'.
(This appears to be intended to make it easier to write correct/consistent CRL parsing programs.)
 
My investigation into CRLs has taken some unexpected turns and I'll post about these. However, I do appear to have achieved the goal that I set myself.
 
In short, I can see that the instance of key compromise has fallen significantly in the last two and a half years, which is probably what everybody in the industry expected and also hoped for. The proof of this comes from the CRLs which *do* include Reason data. Whether you extrapolate that trend to the other CAs is a personal choice. I have chosen to do so but I recognise that others may not. If so, there's no argument here.


#5 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 01 December 2016 - 12:16 AM

As per last post, improving CRLs by including Reason data (for the security cases) really would make quite a significant difference.
 
Reason data can be included in a CRL on a per-entry basis. This is specifically allowed by the RFC and I've viewed at least one CRL file that actually does this.
 
The change that I've suggested would make a real difference at the present time. This is because other methods of handling certificate revocation have not been widely adopted either .... YET.
 
Stapling is a better solution but websites are not doing it en masse. My view: it's not a solution if it's not adopted. More to come on that...
 
Website owners will eventually need to take more responsibility for the security of the connections that their endusers create to the server. If that doesn't happen, the endusers' browsing equipment can be damaged. In the firmware. It's already possible and it's a trend that will increase, if given the opportunity. I note that we already have a working ransom system - a point that is much to our discredit (no pun intended).
 
Therefore, over time, endusers will increasingly require HTTPS on websites and they will also require the system of certificate revocation to be effective. The latter could have an impact on which browser is chosen. Google would like this to be a 'no-brainer' decision but I believe that it isn't, at least not just at the moment. I have some further comments on that. 
 
One of the reasons for this thread is to shine a light on the revocation issue and, ideally, cause useful changes to be made. I argue that some CAs could make a small change to their CRLs and that it would make a big difference, regardless of what happens with stapling. I also have a few suggestions for Google. I know, how dare I ?
 
Stapling is a better solution - please consider implementing this. Secure sites are the future.
 
As always, other views are welcome. 


#6 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 09 December 2016 - 10:19 PM

First of all, thank you Grinler ! I am using HTTPS on this site for the first time, not just login. From memory, this site has OCSP stapling already.
 
 
End-users (whether they realise it or not) and browser suppliers need there to be a solution to revocation.
 
It's complicated at the moment because there are two solutions (one better than the other) but the work to implement each solution comes from different parties: CAs and web-site owners.
 
So there are 4 parties altogether. Two parties need the solution and two further ones can provide it.
 
But stapling, by websites, it isn't happening as a general rule.
 
I see a lower than 50% conformance rate for basic OCSP stapling on sites that have type OV and DV certificates. I'll look more closely but my gut feel, from a list that I produced, is about 30% support. Possibly that raises a good question for Mr Ristic, creator of SSLLabs. My list may best be described as a random selection of those sites which support HTTPS connections (on all pages), in the period Oct-Nov. It certainly isn't focussed on the most popular 100 websites.
 
There is some good news: the Qualys site will soon require support for OCSP stapling (later in 2017) if websites wish to attain an A+ TLS rating. Well done Ivan. For those who want to implement it, there are tutorials online which explain how to turn on basic OCSP stapling.
 
Finally, a small gift: you can check whether your browser recognises Stapling here: https://www.vpnhosting.cz/ocsp
 
As an interested group of parties I feel we should aim to close off attacks on TLS before cyber-criminals make it their preferred attack method. It feels a little bit like complacency.
 
CAs can do more as well. Having said that, if there was another Heartbleed event, CRLs would not cut it.


#7 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 16 December 2016 - 10:06 PM

I should just clarify that final point: if there was another Heartbleed event, CRLs would be far too large and therefore CRLsets would be ineffective.
 
Could there be another Heartbleed event ? I think it's possible because I see the motivation for the hard work that would necessarily go into creating it. I argue that the internet should plan for it.
 
When I choose my browser, I look for a number of things and, cutting to the chase, Chrome meets most of them. And, as a principle, I don't oppose Google's business model - I'm happier that they exist than if they didn't. Why ?
 
If I look back at the attacks that I've witnessed since, about 2011, I'm absolutely amazed at the speed with which Google has adapted to them. Google has implemented HTTPS widely and has led the field. They recognised the danger of attacks on the SHA-1 algorithmic hash. They pin security certificates in Chrome.
 
Certificate revocation is presently something of an achilles heel. I wanted to know to what extent it was and this thread shows what I did to answer that question - it's quite a small risk, at present. I noted that about 2% of revocations were for security reasons. The Chrome browser is not aware of all of them.
 
In the absence of data from the larger CAs, I assumed that 2% is also typical for all CAs.
 
So here is my wish list for the Chrome browser: when I browse to a site using HTTPS, I would like to be informed absolutely what the situation is regarding checks for certificate revocation. (Since the feature may not be one that is generally requested then maybe it could be one that is disabled as the default.)
 
My understanding of the revocation checking process in Chrome is that (i) the browser checks for stapling then (ii) the browser performs OCSP checking on sites that have an EV type certificate. For those which are not EV then (iii) the CRLset will be consulted and a match may or may not be found. The CRLset won't be complete and there's no (iv).
 
With that existing data, the feedback to the end-user could be:
   certificate not revoked (OCSP stapled assertion)
   certificate not revoked (OCSP check)
   certificate revoked (OCSP check)
   certificate revoked (CRLset check)
   certificate status unknown
 
My assumption would be that, in the third and fourth cases, there would be a warning from Chrome to the end-user about proceeding to view the site.
 
It's the other cases that are the issue. I could receive additional information that allows me to distinguish between 'theres no problem' and 'there may be a problem'.


#8 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 16 December 2016 - 10:08 PM

This post is in two parts. Here's the second part.
 
To give an example of how this additional information might be useful: I can tell how many certificates a website has issued in the past and, in some cases, it's clear that there has been duplication. Specifically, a new certificate was issued when another one was already active. This could be for administrative reasons but it could also be as a result of key compromise. If the certificate has been revoked then its serial number should be in one of the CRLs from the issuing CA. If you want, you can check that CRL manually. This thread shows how to do that with any hex editor.
 
If I received this information from the browser :
   certificate status unknown
 
I could then make a decision about the security risk being faced (based on other specific factors). If I felt that it was a case worth looking into further, I would make a note of the certificate serial number and then perform a lookup in the CRL. In other words - a manual revocation check.
 
If the certificate was revoked, regardless of the reason, I would have confirmed that a man-in-the-middle attack had probably occurred. Not everyone would go to these lengths, admittedly, but just the possibility that use of revoked certificates could be detected would provide a deterrent to the certificate system being attacked in the future. Certain classes of attack depend on secrecy i.e. lack of knowledge within the security industry that the attack is ongoing. Use of revoked certificates is a good example of this and the enduring secrecy of the attack (prior to Apr 2014) probably resulted in billions of dollars of additional cybercrime. I have a suspicion that GLIBC was another such case.
 
In summary, at the moment I have to know whether each site staples an assertion and whether it uses an EV certificate or not and, from that, I can infer what the Chrome browser is doing regarding revocation checking. As an enhancement, however, I'd like to have the option to allow the browser to inform me explicitly what the status is and why. That makes it easier to detect man-in-the-middle attacks, in the current situation. 
 
That's my feedback to agl. I hope that it's useful.
 
For information: at one point I did receive confirmation that a site I accessed could not have it's certificate checked. That was when the browser was performing an OCSP check and hard fail was turned on. The check failed consistently. The point being: I have absolutely witnessed this form of attack before. 


#9 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 17 January 2017 - 12:15 AM

In an earlier post I could've mentioned Certificate Transparency, one of several initiatives by Google to make the internet more secure. It's something that I looked at quite closely before starting this thread, just to work out whether it would ever provide a solution to the certificate revocation problem.
 
That's because it's actually very close to what is required. It's an online database of certificates that has high availability (plus redundancy)and the records within it are virtually impossible to fake, so it's highly-dependable as well. A solution for certificate revocation has one further crucially-important feature: the status of the certificate must be capable of changing from 'not yet revoked' to 'revoked'.
 
However, this seems to be incompatible with the Certificate Transparency project, which relies on the records in the database (known as the CT log) not changing, ever. That was my take on it anyway. So Certificate Transparency could not provide a solution for revocation.
 
Last Thursday, however, Google made an early announcement of a similar initiative, this one called Key Transparency. This is intended to provide solutions to multiple internet security issues, including certificate revocation. Here's a link :
 
As stated, this is an early announcement and the technology to deliver it is presently still some way off. It's definitely worth mentioning it here, briefly, but in the meantime we must rely on other, existing ways to inform our browsers about revoked certificates. This means: more https, more stapling by websites and more reason codes (for the security cases) in CRLs please. I'd also like the browser to be able to pass the certificate status (whatever is known about it) to the end-user, on request.
 
It will be interesting to watch Key Transparency as it develops. And I note that Google have invited private contributions to the project, which is a good thing.
 
 
On another matter, I also noticed that the number of CRLs being monitored by SANS has grown recently to 811 (up from about 300 when I first posted about the SANS site). That's a huge piece of work by them, so well done to SANS for that - I'll probably have more to say on this updated SANS resource in a future post. 
 
One message that I'm getting very clearly: people really care about these issues and they are responding. Terrific.


#10 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 09 February 2017 - 09:57 PM

January was very eventful, so this is Update1 for February 2017. And, due to the length, it's another two-parter.
 
SANS is now monitoring the data in 810 CRLs, which I presume is close to all of the CRLs issued by all CAs in the world.
 
The difference between one version of a CRL and the last version is a set of very useful information, namely which certificates have been revoked in the last period (typically 4-10 days). It's not hard to extract this change data and SANS are already doing that. Similarly, in the same period, a certain number of certificates would have reached their end-of-life, which means they would be present in the older version of the CRL, but not present in the latest one.
 
If just the change data was collected (and accumulated, say over a month) this could be used to generate two figures per CRL that indicate how many certificates were revoked in the last month and how many became irrelevant due to EoL. If these figure were summed across all CRLs, and then plotted as graph, it would provide two trend indicators. One would be the trend of how many certificates were being removed from CRLs monthly and the other would be the trend of how many certificates were being added to CRLs monthly.
 
It's useful to have this data because it helps to understand how more efficient CRLsets are going to become (or not) over time. And the difference between the two graphs would indicate the overall trend of increase or decrease, over time. Again, quite useful.
 
Perhaps the most useful trend graph of all would be one which displays the total number of revoked certificates present in all CRLs at any point of time. The simplest way to get the total revoked certificate population would be to sum the number of serial numbers present in all CRLs, say at the end of each month. If all CRLs are being monitored, then this figure becomes fairly easy to obtain. My guess is that SANS will be generating this graph, and I note that the data is already available. There are columns in the CRL list (and they've been there for a while) : 
   CRL total size (i.e. total revoked certificates listed)
   certificates revoked in the last 30 days
 
So this information is already available, per CRL.


#11 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 09 February 2017 - 10:03 PM

(Part 2)
 
There is one caution about the data on the SANS site :
"You may find that particular certificates are included in more than one CRL."
 
 
Using the new graph (and ignoring the large peaks over 5000), I estimate that the current weekly rate of revocation is about 16,000. That's higher than during most of 2016. For example, I estimate that in May the weekly rate was about 11,000. 
 
So that graph is very useful already. I don't have the reason for the recent increase but I would hazard a guess that it is due to the increasing popularity of short-duration certificates issued by Lets Encrypt. Revocation could be due to certificates being superceded and, in the CRL that I examined closely, 'superceded' was accounting for more than 40% of revocations.
 
There's an inherent benefit to CRLsets when websites give their certificates a shorter working life. These revoked certificates disappear from CRLs far, far quicker. I note that certificates issued by Lets Encrypt last about 3 months and are replaced automatically when they expire - a very useful, efficient improvement. 
 
All security-conscious websites have the option to use shorter-lived certificates if they choose to do so, even where the issuing CA is not Lets Encrypt. This is something Google elected to do some time ago - their certificates have an 84-day duration (if I recall). And, separately, Google recently proposed a change, in the CA-Browser forum, that all new EV certificates should be limited to a working life of 12 months, down from 2 years in many cases. Initiatives such as these reduce the threat posed by revoked certificates at a time when revocation isn't working at all well.
 
Here's a link to Google's proposal, initiated by Ryan Sleevi, on 31st Jan 2017 
(it's actually the result of ballot #183) :
That proposal was quickly approved, leading to a further ballot, dated 9th Feb (today), to finalise the details
The situation is changing as I write - the preference currently appears to be for a maximum EV certificate duration of 398 days (13 months), effective as of 1st May 2017. Readers who would like to see a running commentary, and the final outcome, could do worse than take a look here :
 
I can only describe the speed of this development, start to finish, as highly encouraging. 
 
As background: EV certificates are particularly sensitive, being used to protect banking (and other critical) websites. 
 
 
One final note: the SANS graph requires your browser to process large amounts of data. If you are prompted about lack of response, just allow it to continue.


#12 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 23 February 2017 - 12:27 AM

Update2 for February. I counted 11 votes cast on ballot 185 and CAs were generally against Limiting the Lifetime of Certificates. Google, Mozilla and ISRG voted in favour but failed to win the ballot.
 
When they gave a reason for their vote, CAs generally spoke about the considerations of their customers i.e. website owners. The view of CAs was that website owners were not keen on the additional work involved in changing the site certificate every 13 months.
 
Without wading in to that debate too far, this argument is really only about cost. Cost is uppermost in the mind of a successful business operator but, on the other hand, security also has the ability to affect cost, especially when security is not implemented adequately. There have been some very high profile, costly website failures. No need to name names. And where a website cuts down on security, it is necessarily weaker, which means that it's more likely to be a target. That message may or may not be reaching the financial decision-makers in any given company. It depends upon many factors.
 
Turning to an example... Suppose that a website has an OV certificate, one which has a lifetime of 36 months and, additionally, the site has not yet implemented OCSP stapling. If that certificate had its key compromised, the website would notify the CA and revoke the certificate as soon as this fact was discovered, meanwhile replacing it. However, since the revocation system doesn't work well for OV certificates, the certificate would appear, effectively, as 'not revoked', to many browsers, and that would be the case for up to 3 years. In that time the secure connections of end-users to the website would be at risk of interception. However, if OCSP stapling was implemented on the website, it would prevent a lot of those browsers mistakenly accepting the revoked certificate, should it ever be used by an attacker. Certificates with shorter lives help by reducing the period of exposure. Separately, stapling is very helpful in boosting security.
 
Therefore, when I look at the certificate of a website (for types OV and DV), in practice I like to see either a short lifetime on the certificate, or that OCSP stapling has been implemented on the website. Of course, there's a similar argument for reducing the life of EV certificates as well, but for a different reason (see the last post - reduce the size of CRLsets).
 
But here's a question: it's been mentioned that labour cost is an argument against reducing the lifetime of a website certificate, so would a website be better or worse off if it 'downgraded' from an OV certificate to DV, assuming that the DV certificate was short-lived and replaced automatically (zero labour cost) and at no charge (zero cost again) ?
 
The site would lose a little by not going through the full verification process that comes with OV but it may gain a lot more. If labour cost really is the issue then this is worth thinking about.
 
I haven't actually answered that question but it makes me think that CAs should be having a broader discussion with their clients, especially those with OV and DV certificates. 
 
In this thread I've already had a lot of comments to make, which is without trying to explain how OCSP stapling works. Such a task is non-trivial. It's therefore useful that Scott Helme has provided a description of OCSP stapling and the enhancement to it, OCSP Must-Staple
 
The original source for this discussion was a page on Steve Gibson's website : 
(stapling is discussed about half way down)
 
This revocation investigation ( and others that I haven't yet mentioned ) was inspired by Security Now podcasts. So it's highly appropriate for me to congratulate Steve and Leo on reaching the amazing milestone of 600 podcasts, which happened this week !
 
You guys are the original, security-conscious carers of the computing industry. Respect !
 
 
edit: add the missing letters, and so on
 

Edited by palerider2, 23 February 2017 - 11:21 PM.


#13 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 22 March 2017 - 08:30 PM

One topic that comes up fairly frequently in various places is security within CAs and, in this regard, there were two new incidents in January this year. The incidents have been discussed fairly broadly already, so I won't provide the details again.
 
The certificate system is periodically threatened when certificates are issued by CAs where the website owner hasn't asked for it to happen nor have they been informed of the issuance of 'their' certificate. This means that, for a period of time, a phishing website could pretend to be the real website and also accept HTTPS connections from end-users. In turn, that means the rogue site could gather secure information from end-users, including logon credentials, credit card numbers, birthdates and so on. There's lots of information there that can be used in later attacks, where the end-user could be impersonated on the real website and (potentially) on other sites as well.
 
Certificate Transparency (CT) was put in place to help detect such certificate misissuance, so for misissuance to have occurred again, in 2017, is something of a surprise. In fact, the CA that did it was already on 'strike 1', as you might say, if using a baseball term. However, through CT logs working as they should, the same CA was detected again and is now, arguably, at 'strike 2' !  Draw your own conclusions on why that happened and whether it will happen again ...
 
However, consequent to this, there has been a further response from the CA/Browser forum. An initiative called CAA, which was initially launched in 2013, will now become mandatory in Sept 2017. This effectively blocks the majority of CAs from misissuing certificates in the way that happened in January.
 
Website owners will be able to create a whitelist of CAs who are allowed to issue certificates for their sites. If the number of whitelisted CAs drops from (say) 600 to just 3 (per website) then that represents a great solution. Compared to the previous situation, the 'bullet' will now hit the target with 99.5% accuracy. (And arguably, it will be 100%, in practice). Each website will have theor own preferred CAs.
 
CT is a very effective tool in detecting misissued certificates but it requires an individual to do the actuak research in the CT logs. So, CAA goes further and it could be a very good solution.
 
There could be other consequences too. Imagine that a whole group of sensitive website owners fail to add a particular untrusted CA to their whitelist. That CA is then pressurised to either to become trustworthy (and convince people that they are ! ) or sign their own death warrant. It's not overly harsh - CAs need to be trustworthy.
 
CAA has the potential to form part of a really powerful system, so full credit to CAs for voting this through. The same goes almost without saying for the browser suppliers. This change appears to be a really good improvement for internet security !
 
A link for some further detail :
 
The Domain Name lookup system forms part of the CAA solution and DNS is not secure, which is why I used the word 'potential' earlier. However, mandating CAA now creates another reason why DNSSEC should be rolled out, and thereby support CAA securely.
 
(CAA is the acronym for Certificate Authority Authorisation. It limits the authority of CAs and is one of the initiatives that derived from CAs' efforts to regulate themselves, through their 'Baseline Requirements'.)


#14 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 18 May 2017 - 10:59 PM

One of the issues raised earlier in this thread was the low-ish deployment of basic OCSP stapling. I took a cursory look at this for both OV and DV-certified websites. You may recall that I originally reported about 30% deployment of OCSP stapling. At the time, nobody (that I could detect) had implemented Must Staple, the upgrade of basic OCSP stapling. That's changed now, of course - thank you Scott H ! 
 
Since the start of May I've tested a number of web sites, so here are the results for those sites which had deployed TLS and had obtained a certificate after the beginning of 2017. (It's interesting to add that second condition).
 
The DV results (random sites that I hadn't accessed before) are below :
  Sites tested:              12
  Using basic stapling: 7        58%
  no stapling                  5
 
Out of the 5 which had no basic OCSP stapling
  3-month cert               3
 13-month cert              2
 
(Arguably, 3 of those non-stapling sites are providing an assurance of 'not revoked' to their users on a 3-monthly basis, as compared to a daily basis, with stapling. In the other 2 cases, there's still a fairly short-duration certificate and this indicates (again arguably) an awareness of the revocation problem. For those sites, the next best step could be to add basic OCSP stapling.)
 
In the group of sites where the certificate was issued earlier than Jan 2017, here are the results :
  Sites tested:               3
  Using basic stapling: 1       (certificate obtained Dec 2016)
  no stapling                 2
 
It looks as though the deployment of basic OCSP stapling is rising, in particular where sites are either
  - implementing TLS for the first time or
  - updating their certificate
 
 
Just returning to that point about 'next best step'. It's an interesting one and worth linking to one of the experts.
 
For those who want to incrementally turn their website into a fortress, you could do a lot worse than run your site past the Mozilla observatory test and take their advice. Some comments on the Mozilla approach :
-  If you haven't implemented HSTS you will receive: grade F (I think this comment is accurate)
-  Content Security Policy header is highly-rewarded
-  So is Subresource Integrity
-  Whatever the state of your site, there is advice for how to change things one step at a time, in order to improve it
 ... then retest
 
That last point strikes me as a great approach to ramping up site performances, whilst acknowledging that everyone has a schedule. Therefore, do it incrementally, one improvement per week. Or whatever fits the schedule. At least it will get you there, rather than standing still ... nice approach.  :thumbup2:


#15 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:09:44 AM

Posted 22 May 2017 - 10:46 PM

If you haven't implemented HSTS you will receive: grade F
 
What follows is the accurate statement, as of May 2017 :
If a website hasn't implemented HSTS it will typically receive: grade F from the Mozilla Observatory test site. Today.
 
This outcome is not by design, it's because (at present) there's a correlation between websites that haven't implemented the HSTS header and sites which haven't implemented many of the other headers, such as Content Security Policy (CSP).
 
So if you test a site that hasn't yet implemented HSTS, the score is probably going to be quite low. If the score is below about 25, then the grade will be F. I would expect that the cut-off for grade F may change over time. I tested a few sites. As of May 2017, they obtained the grades and scores as follows :
B (70), C+ (60), D+ (40), D- (25), F (20)
 
The above correction is just about clarifying that Mozilla has used a graded scoring system.
 
 
Returning to revocation checking, there's been useful feedback on the implementation of basic OCSP stapling and on MUST staple. The first link (below) provides a guide to implementing basic stapling on the nginx platform :
but there can be issues ...
I'd recommend reading the final paragraph, that has title : 'Gotchas'
 
Turning to the second part of the feedback, from Hann Boeck :
 
Hanno confirms that his implementation of basic stapling just about works and he provides the settings for his Apache platform, some of which were non-intuitive. However, he makes the same point as Scott that Apache's implementation of basic Stapling still requires some work by the supplier, to make it reliable.
 
Until basic OCSP stapling is reliable on the server it's not a good idea to advance to the MUST staple stage.
 
It sounds like Scott is still investigating how reliable basic stapling is on his nginx server. The remainder of his blog about Expect staple indicates his approach to getting that information and, in time, one which everyone could use.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users