Henry,
Yes - revocation works on serial number, but if the key-pair has not been
changed and the private key has been compromised the unrevoked certificate
is also compromised.
Regards
Dave
------------------------------------------------
Dr David Kelsey
Particle Physics Department
Rutherford Appleton Laboratory
Chilton, DIDCOT, OX11 0QX, UK
e-mail: [log in to unmask]
Tel: [+44](0)1235 445746 (direct)
Fax: [+44](0)1235 446733
------------------------------------------------
On 09/04/2014 10:15, "Henry Nebrensky" <[log in to unmask]> wrote:
>> So I need new host certs (not to renew old ones) according to Lief.
>>Renewal
>> does not cut it. Have I got that right?
>
>I don't understand why renewal wouldn't acceptable - certificates are
>identified / revoked by their serial number, and I don't think there's
>anything in the certificate itself that tells you it's a renewal.
>(Possibly there are short-term concerns about the CA infrastructure being
>vulnerable?)
>
>And I don't see how the DN comes into it - how do I make the DN of an SE
>host different, without changing the hostname and thus screwing up the
>catalogues?
>
>Any chance of an explanation for us thick people?
>
>Thanks
>
>Henry
>
>
>
>On Wed, 9 Apr 2014, Stephen Jones wrote:
>> 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/
>>
>
>--
>Dr. Henry Nebrensky [log in to unmask]
> http://people.brunel.ac.uk/~eesrjjn
>"The opossum is a very sophisticated animal.
> It doesn't even get up until 5 or 6 p.m."
--
Scanned by iCritical.
|
