Hi all,
I'm trying to get perfect clarity on this process to make sure it works.
According to
Leif Nixon (egi security officer), the mitigations include this:
> Then sites will need new certificates for the previously
> vulnerable hosts. Once the site has installed the new certificates,
> the old ones must be revoked.
This mitigation implies that new certificates are required, prior to
revoking old ones. The systems continue to work with old certificates.
The new certificates are installed. The systems work with new certificates.
Old certificates are then revoked. Mitigation is complete.
So I need new host certs (not to renew old ones) according to Lief.
Renewal does not
cut it. Have I got that right?
But John(K) implies there is some problem with this, i.e.
> You can temporarily suspend your certificate by requesting its
revocation. The
> problem with this is that if that request is signed then your
certificate goes "bang".
John(H) has also alluded to a problem:
> I don't think the same procedure will work, as the DN of the replacement
> certificate will be the same as the existing one.
John(K) and John(H) - are these the same problem? Are we saying that we
can't have two valid
certificates for the same box? The reason for asking is that I'd prefer
to do nothing but
apply for new certificates, get them, install them, revoke the old ones.
I'd prefer not to
get a friendly RA Op from another RA to request the revocation for me,
and persuade
my RA Op's approval to delay the process, because this is almost
guarenteed to go wrong
sometime, somehow - too many folks in the loop.
In short, is there a cleaner way to do this that doesn't involve making
deals with various
RA Ops hither and thither in a manner that is likely to break down? And if I
do have to make a deal with some remote friendly RA Op, who would volunteer?
Any ideas?
Cheers,
Steve
On 04/08/2014 05:50 PM, John Kewley wrote:
> For those of you want to request a New host cert rather than do a Renewal.
>
> You can temporarily suspend your certificate by requesting its revocation.
> The problem with this is that if that request is signed then your certificate goes "bang".
> The alternative is to get a friendly RA Op from another RA to request the revocation for you.
> This means that it will await your RA Op's approval (which you persuade them not to give ... just yet).
> You can now apply for a new one
>
> cheers
>
> JK
>
>> -----Original Message-----
>> From: Stephen Jones [mailto:[log in to unmask]]
>> Sent: Tuesday, April 08, 2014 5:08 PM
>> To: [log in to unmask]
>> Subject: I'll test this out: https://www.gridpp.ac.uk/wiki/Grid_Certificate
>>
>> Hi all,
>>
>> I wrote some of this a while back. Now I have to renew all the certs due to
>> the OPENSSL bug, I guess I should test it still works:
>>
>> I think it's the same process as "Converting host certificates to omit the
>> email addresses from DNs".
>>
>> https://www.gridpp.ac.uk/wiki/Grid_Certificate
>>
>> Job for tomorrow...
>>
>>
>> Steve
>>
>> --
>> Steve Jones [log in to unmask]
>> System Administrator office: 220
>> High Energy Physics Division tel (int): 42334
>> Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334
>> University of Liverpool http://www.liv.ac.uk/physics/hep/
** WHITE information - Unlimited distribution allowed **
** seehttps://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions **
EGI CSIRT ADVISORY [EGI-ADV-20140408]
Title: EGI SVG Advisory 'Critical' RISK - CVE-2014-0160 affecting OpenSSL [EGI-ADV-20140408]
Date: 2014-04-08
Updated: <date yyyy-mm-dd>
URL:https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/OpenSSL-2014-04-08
Introduction
============
A vulnerability has been found in OpenSSL which allows unauthenticated
remote attackers to access memory areas in vulnerable systems.
It has been assigned CVE-2014-0160 [R 1].
Linux distributions with vulnerable OpenSSL versions include RHEL 6.5
and derivatives, and Ubuntu 12.04.4 LTS. In particular, note that RHEL
6.4 and earlier are not affected.
Details
=======
This vulnerability affects systems using OpenSSL.
OpenSSL has issued a brief advisory on this issue [R 2]
A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64kB of memory to a connected client or server.
This allows sensitive information like passwords, session cookies and
contents of encrypted messages to be revealed to an unauthenticated
user.
Sites need to patch vulnerable systems, with priority given to servers
exposing SSL services, not forgetting to restart the services
afterwards.
Sites will then need new certificates for the previously vulnerable
hosts.
The vulnerability also affects client software that uses OpenSSL,
which means that clients that connect to a malicious server could
suffer from information leak.
Risk category
=============
This issue has been assessed as 'Critical' by the EGI SVG Risk Assessment Team
and the CSIRT Team.
Affected software
=================
OpenSSL Versions 1.0.1 [a through f].
This issue is fixed in OpenSSL 1.0.1g. Versions of OpenSSL earlier
than 1.0.1 are not affected.
Linux distributions with vulnerable OpenSSL versions include RHEL 6.5
and derivatives, and Ubuntu 12.04.4 LTS. In particular, note that RHEL
6.4 and earlier are not affected.
Mitigation
==========
N/A
Component installation information
==================================
All sites running a vulnerable OpenSSL version must upgrade to a
patched version. Updates have been released by Red Hat, CentOS and
Ubuntu and others.
Priority should be given to servers exposing SSL services, not
forgetting to restart the services afterwards.
Then sites will need new certificates for the previously vulnerable
hosts.
Once the site has installed the new certificates, the old ones must be
revoked.
Recommendations
===============
All running resources MUST be either patched or temporarily removed
From service as soon at possible, and at the latest by
2014-04-15T21:00+01:00. Sites failing to act and/or failing to respond
to requests from the EGI CSIRT team risk site suspension.
Sites will then need new certificates for the previously vulnerable
hosts. EGI CSIRT recommends that this is done in a staggered fashion
according to how important/sensitive the services are, to ease the
load on CA:s. Please note that this should only be done for hosts that
have been running a vulnerable version of OpenSSL.
Sites should then revoke the old certificates.
Then, finally, sites need to evaluate what other information that has
been potentially exposed by this; e.g. passwords that were submitted
to vulnerable servers.
Credit
======
EGI SVG and CSIRT was alerted to this vulnerability by Raul Lopes and
David Kelsey.
References
==========
[R 1]http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160
[R 2]http://www.openssl.org/news/secadv_20140407.txt
[R 3]https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-0160
Timeline
========
Yyyy-mm-dd
2014-04-08 EGI and SVG alerted to this Publicly disclosed vulnerability
2014-04-08 Acknowledgement from the EGI SVG
2014-04-08 EGI SVG and CSIRT consider 'Critical'
2014-04-08 Alert issued with 7 day deadline
On behalf of the EGI CSIRT and SVG,
-- Leif Nixon - Security officer National Supercomputer Centre - Swedish
National Infrastructure for Computing Nordic Data Grid Facility -
European Grid Infrastructure
--
Steve Jones [log in to unmask]
System Administrator office: 220
High Energy Physics Division tel (int): 42334
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334
University of Liverpool http://www.liv.ac.uk/physics/hep/
|