Quantcast

OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Michael D-3
Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28629 


Does anybody have any experience with this security patch?

It seems to affect older versions of openssl (0.9.7 or so)... does anybody have experience with newer 
versions?

[Basically after the patch is added..older openssl versions can't maintain a connection]

Thank you,

-Mike
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Jakob Bohm-7
On 2/29/2012 12:22 AM, Michael D wrote:
> Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)
> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28629
That page only instructs how to download the update
file for that particular build of Windows.

The real meat of the description is in

    KB2643584 http://support.microsoft.com/kb/2643584

which (directly and indirectly) refers to

   For SSL 3.0: RFC6101 Paragraph 5.2.1
      http://tools.ietf.org/html/rfc6101#section-5.2.1
   For TLS 1.0: RFC2246 Paragraph 6.2.1
      http://tools.ietf.org/html/rfc2246#section-6.2.1
   MS12-006
      http://technet.microsoft.com/en-us/security/bulletin/ms12-006
   CVE-2011-3389

Basically, this update causes Microsoft's own SSL library (SCHANNEL)
to split some data records in cases permitted but not required by
the SSL/TLS standards in order to avoid a known attack on the
standard protocol without this extra splitting.  This extra splitting
is done only if SCHANNEL is called with an extra option bit, which
other updates have then added to some other Microsoft products (such
as Internet Explorer and the unrelated WinHTTP curl-like library).

Microsoft warns deep down in KB2643584 that some applications cannot
cope with receiving the split packets and suggests using a new system
setting to TEMPORARILY force disable the splitting until such
applications have been fixed in your particular setup.

>
>
> Does anybody have any experience with this security patch?
>
> It seems to affect older versions of openssl (0.9.7 or so)... does anybody have experience with newer
> versions?
>
> [Basically after the patch is added..older openssl versions can't maintain a connection]

In relation to OpenSSL, the following 3 questions remain open:

1. Are any versions of OpenSSL's own protocol library code unable
to cope with the CVE-2011-3389 additional record splitting?

2. Are any versions of OpenSSL's utility and command line programs
(such as s_client and s_server) unable to cope with the CVE-2011-3389
additional record splitting in cases where OpenSSL itself copes just
fine?

3. Is the application you use with OpenSSL unable to cope with the
CVE-2011-3389 additional record splitting in cases where OpenSSL
itself copes just fine?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Tammany, Curtis
I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites"). With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I could not make a connection. We rolled back versions of OpenSSL until we got to 0.9.8r which could make a connection with both protocols enabled on the browser...

Will there be a version that will address MS12-006? TLS1.1? TLS1.2?


Curtis N. Tammany
Lead Web Application Developer, National Security & Defense
Systems Engineering and Technology
URS
16156 Dahlgren Road
Dahlgren, Virginia, 22448
[hidden email]
540.663.9507


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jakob Bohm
Sent: Wednesday, February 29, 2012 08:44
To: [hidden email]
Subject: Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

On 2/29/2012 12:22 AM, Michael D wrote:
> Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)
> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28629
That page only instructs how to download the update
file for that particular build of Windows.

The real meat of the description is in

    KB2643584 http://support.microsoft.com/kb/2643584

which (directly and indirectly) refers to

   For SSL 3.0: RFC6101 Paragraph 5.2.1
      http://tools.ietf.org/html/rfc6101#section-5.2.1
   For TLS 1.0: RFC2246 Paragraph 6.2.1
      http://tools.ietf.org/html/rfc2246#section-6.2.1
   MS12-006
      http://technet.microsoft.com/en-us/security/bulletin/ms12-006
   CVE-2011-3389

Basically, this update causes Microsoft's own SSL library (SCHANNEL)
to split some data records in cases permitted but not required by
the SSL/TLS standards in order to avoid a known attack on the
standard protocol without this extra splitting.  This extra splitting
is done only if SCHANNEL is called with an extra option bit, which
other updates have then added to some other Microsoft products (such
as Internet Explorer and the unrelated WinHTTP curl-like library).

Microsoft warns deep down in KB2643584 that some applications cannot
cope with receiving the split packets and suggests using a new system
setting to TEMPORARILY force disable the splitting until such
applications have been fixed in your particular setup.

>
>
> Does anybody have any experience with this security patch?
>
> It seems to affect older versions of openssl (0.9.7 or so)... does anybody have experience with newer
> versions?
>
> [Basically after the patch is added..older openssl versions can't maintain a connection]

In relation to OpenSSL, the following 3 questions remain open:

1. Are any versions of OpenSSL's own protocol library code unable
to cope with the CVE-2011-3389 additional record splitting?

2. Are any versions of OpenSSL's utility and command line programs
(such as s_client and s_server) unable to cope with the CVE-2011-3389
additional record splitting in cases where OpenSSL itself copes just
fine?

3. Is the application you use with OpenSSL unable to cope with the
CVE-2011-3389 additional record splitting in cases where OpenSSL
itself copes just fine?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Jakob Bohm-7
Thanks for that piece of information, it wasn't at all clear
from the context and subject lines.

I do not know why MS KB2643584 does not mention changing TLS 1.1
and/or TLS 1.2 behavior, maybe someone familiar with the attack
described in CVE2011-3389 knows a reason.

My general guess at this time is that the MS workaround of
artificially splitting certain unspecified SSL records is not the
only way to fix CVE2011-3389 and that this particular workaround
has not been tested by the OpenSSL core team.

I hope that now that we have apparently tracked this to a general
MS implementation change which is unrelated to the restricted CAC
hardware, that figuring out the OpenSSL compatibility issue will
be a lot easier than when only USG employees and contractors with
a CAC card could do the testing.

On 2/29/2012 8:40 PM, Tammany, Curtis wrote:

> I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites"). With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I could not make a connection. We rolled back versions of OpenSSL until we got to 0.9.8r which could make a connection with both protocols enabled on the browser...
> Will there be a version that will address MS12-006? TLS1.1? TLS1.2?
> Curtis N. Tammany
> Lead Web Application Developer, National Security&  Defense
> Systems Engineering and Technology
> URS
> 16156 Dahlgren Road
> Dahlgren, Virginia, 22448
> [hidden email]
> 540.663.9507
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Jakob Bohm
> Sent: Wednesday, February 29, 2012 08:44
> To: [hidden email]
> Subject: Re: OpenSSL&  "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"
> On 2/29/2012 12:22 AM, Michael D wrote:
>> Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)
>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28629
> That page only instructs how to download the update
> file for that particular build of Windows.
> The real meat of the description is in
> KB2643584 http://support.microsoft.com/kb/2643584
> which (directly and indirectly) refers to
> For SSL 3.0: RFC6101 Paragraph 5.2.1
> http://tools.ietf.org/html/rfc6101#section-5.2.1
> For TLS 1.0: RFC2246 Paragraph 6.2.1
> http://tools.ietf.org/html/rfc2246#section-6.2.1
> MS12-006
> http://technet.microsoft.com/en-us/security/bulletin/ms12-006
> CVE-2011-3389
> Basically, this update causes Microsoft's own SSL library (SCHANNEL)
> to split some data records in cases permitted but not required by
> the SSL/TLS standards in order to avoid a known attack on the
> standard protocol without this extra splitting. This extra splitting
> is done only if SCHANNEL is called with an extra option bit, which
> other updates have then added to some other Microsoft products (such
> as Internet Explorer and the unrelated WinHTTP curl-like library).
> Microsoft warns deep down in KB2643584 that some applications cannot
> cope with receiving the split packets and suggests using a new system
> setting to TEMPORARILY force disable the splitting until such
> applications have been fixed in your particular setup.
>> Does anybody have any experience with this security patch?
>> It seems to affect older versions of openssl (0.9.7 or so)... does anybody have experience with newer
>> versions?
>> [Basically after the patch is added..older openssl versions can't maintain a connection]
> In relation to OpenSSL, the following 3 questions remain open:
> 1. Are any versions of OpenSSL's own protocol library code unable
> to cope with the CVE-2011-3389 additional record splitting?
> 2. Are any versions of OpenSSL's utility and command line programs
> (such as s_client and s_server) unable to cope with the CVE-2011-3389
> additional record splitting in cases where OpenSSL itself copes just
> fine?
> 3. Is the application you use with OpenSSL unable to cope with the
> CVE-2011-3389 additional record splitting in cases where OpenSSL
> itself copes just fine?
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Dr. Stephen Henson
In reply to this post by Tammany, Curtis
On Wed, Feb 29, 2012, Tammany, Curtis wrote:

> I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites").
> With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection
> to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I
> could not make a connection. We rolled back versions of OpenSSL until we got
> to 0.9.8r which could make a connection with both protocols enabled on the
> browser...
>
> Will there be a version that will address MS12-006? TLS1.1? TLS1.2?
>
>

At present I cannot reproduce the issues with MS12-006 so I can only guess as
to the cause. If I can or I can get appropriate feedback I can work on a fix,
assuming it isn't fixed already: see below. TLS 1.1 and 1.2 will only ever
appear in OpenSSL 1.0.1 and later as new features don't appear in stable
releases: just bug fixes. That is currently in beta and a few issues remain to
be resolved before the full release.

So a few guesses:

If the problem is no longer present in OpenSSL 0.9.8r then 1.0.0e may also
work. The only known problem with later versions is the SGC DoS fix has a bug
in it which may affect renegotiation in some circumstances. This bug *should*
be fixed in the latest snapshots of OpenSSL: please see if they work OK for
you.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Jakob Bohm-7
On 2/29/2012 11:43 PM, Dr. Stephen Henson wrote:

> On Wed, Feb 29, 2012, Tammany, Curtis wrote:
>
>> I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites").
>> With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection
>> to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I
>> could not make a connection. We rolled back versions of OpenSSL until we got
>> to 0.9.8r which could make a connection with both protocols enabled on the
>> browser...
>>
>> Will there be a version that will address MS12-006? TLS1.1? TLS1.2?
>>
>>
> At present I cannot reproduce the issues with MS12-006 so I can only guess as
> to the cause. If I can or I can get appropriate feedback I can work on a fix,
> assuming it isn't fixed already: see below. TLS 1.1 and 1.2 will only ever
> appear in OpenSSL 1.0.1 and later as new features don't appear in stable
> releases: just bug fixes. That is currently in beta and a few issues remain to
> be resolved before the full release.
Please read that again.  He wrote that 1.0.0 did NOT work, but 0.9.8 works.
>
> So a few guesses:
>
> If the problem is no longer present in OpenSSL 0.9.8r then 1.0.0e may also
> work. The only known problem with later versions is the SGC DoS fix has a bug
> in it which may affect renegotiation in some circumstances. This bug *should*
> be fixed in the latest snapshots of OpenSSL: please see if they work OK for
> you.
Please refer to my initial literature check higher up in this thread.

MS12-006 is Microsoft's name for CVE-2011-3389, which you hopefully
know better than I do.

Microsoft KB2643584 et al is Microsoft's patch for CVE-2011-3389.

According to Microsoft, their patch selectively fragments some of the
SSL and TLS records in order to prevent the attack.  They claim that
this fragmentation is the most likely cause of interoperability issues
and point to specific clauses in the SSL 3.0 and TLS 1.0 RFC's as
justification for saying that any incompatible software (which might
include OpenSSL 1.0.0) is buggy for not being compatible with their
change, although that might just be BS.

--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
<call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Dr. Stephen Henson
On Thu, Mar 01, 2012, Jakob Bohm wrote:

> On 2/29/2012 11:43 PM, Dr. Stephen Henson wrote:
> >On Wed, Feb 29, 2012, Tammany, Curtis wrote:
> >
> >>I had brought this issue up earlier ("Windows 7/IE8 CAC enabled sites").
> >>With SSL 3.0 only checked on IE8 (in windows 7), I could make a connection
> >>to my site that had OpenSSL 1.0.0g. With both SSL 3.0 AND TLS 1.0 checked, I
> >>could not make a connection. We rolled back versions of OpenSSL until we got
> >>to 0.9.8r which could make a connection with both protocols enabled on the
> >>browser...
> >>
> >>Will there be a version that will address MS12-006? TLS1.1? TLS1.2?
> >>
> >>
> >At present I cannot reproduce the issues with MS12-006 so I can only guess as
> >to the cause. If I can or I can get appropriate feedback I can work on a fix,
> >assuming it isn't fixed already: see below. TLS 1.1 and 1.2 will only ever
> >appear in OpenSSL 1.0.1 and later as new features don't appear in stable
> >releases: just bug fixes. That is currently in beta and a few issues remain to
> >be resolved before the full release.
> Please read that again.  He wrote that 1.0.0 did NOT work, but 0.9.8 works.

He mentioned rolling back to 0.9.8r. I was double checking that no 1.0.0
release actually worked. My reason is that a change introduced in 0.9.8s
related to SGC could break some operations with MSIE unrelated to SGC:
specifically renegotiation, which client authentication makes use of.

> >
> >So a few guesses:
> >
> >If the problem is no longer present in OpenSSL 0.9.8r then 1.0.0e may also
> >work. The only known problem with later versions is the SGC DoS fix has a bug
> >in it which may affect renegotiation in some circumstances. This bug *should*
> >be fixed in the latest snapshots of OpenSSL: please see if they work OK for
> >you.
> Please refer to my initial literature check higher up in this thread.
>
> MS12-006 is Microsoft's name for CVE-2011-3389, which you hopefully
> know better than I do.
>
> Microsoft KB2643584 et al is Microsoft's patch for CVE-2011-3389.
>
> According to Microsoft, their patch selectively fragments some of the
> SSL and TLS records in order to prevent the attack.  They claim that
> this fragmentation is the most likely cause of interoperability issues
> and point to specific clauses in the SSL 3.0 and TLS 1.0 RFC's as
> justification for saying that any incompatible software (which might
> include OpenSSL 1.0.0) is buggy for not being compatible with their
> change, although that might just be BS.
>

Well OpenSSL should cleanly deal with fragments. In fact it is other
implementations that have had issues with OpenSSL using empty fragments
that cause problems. Ironically it was as a work around for this very issue.

So while fragmentation is a possible cause I'd consider it unlikely and I
can't think of any changes after 0.9.8r that would have broken that.

The use of TLS 1.1 and 1.2 in MSIE might have an effect: if there are
interop problems with MS TLS 1.1,1.2 and older versions of OpenSSL. Though I
don't know why the OP would also need to disable TLS 1.0.

Since I can't reproduce this I'm wondering if the CAC cards introduce an
additional element. I can see two possible reasons why they might:

1. Client authentication requires renegotiation if it is enabled on certain
webpages and not across the whole site. The was a problem with version numbers
in premaster secrets with IIS which has been fixed: I wonder if there is a
similar one with MSIE which affects OpenSSL servers.

2. Renegotiation might trigger the SGC bug.

However none of these precisely fits the facts: I'd expect both to give some
characteristic errors in the log and not affect TLS 1.0.

Anyway to answer the OPs earlier request about s_server. It can behave like a
mini test webserver and can print out useful diagnostics. A command like:

openssl s_server -cert cert.pem -www

Will start it and you can then access this at port 4433 i.e.:

https://www.host.com:4433/

That by default will not request client authentication. If you include -verify
9 on the command line it will.

I'd be interested to know if you can connect to that server with or without
client authentication.

That isn't a complete test though as it doesn't include an option to
selectively request client authentication on certain web pages: which I
suspect the website causing problems does.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

Dave Thompson-5
In reply to this post by Jakob Bohm-7
> From: [hidden email] On Behalf Of Jakob Bohm
> Sent: Wednesday, 29 February, 2012 15:51

> I do not know why MS KB2643584 does not mention changing TLS 1.1
> and/or TLS 1.2 behavior, maybe someone familiar with the attack
> described in CVE2011-3389 knows a reason.
>
Well, at least with the description. AFAICS they didn't
release some of the details needed for the actual attack.
(Which probably was wise.)

TLS1.1 changes CBC mode to randomize the IV per record instead
of chaining as SSL/TLS1.0 did, and thus is immune (if correctly
implemented, as always). (And TLS1.2 keeps this improvement.)

> My general guess at this time is that the MS workaround of
> artificially splitting certain unspecified SSL records is not the
> only way to fix CVE2011-3389 and that this particular workaround
> has not been tested by the OpenSSL core team.
>
The fix simply sends two appdata records, first with length=1
and second with length=N-1. OpenSSL returns them separately,
which applications might not handle (choice #3 in your list).

SSL/TLS always promised "stream not guaranteeing boundaries"
service like TCP which it was/is intended to substitute for.
TCP apps do encounter splitting and joining in the real net
and have had to cope with it or be limited to backwaters.
But SSL/TLS implementations mostly *did* preserve boundaries
before this fix (they have to do record-level processing anyway,
while TCP does segments directly on IP) and apps/programmers
have tended to rely on it by mistake or laziness.

OpenSSL some years back tried sending a record with length=0
and then the real one (length=N), which also defeats the attack
but is more debatable and certainly counterintuitive and
was found to cause problems with other implementations.
It might work better now; I haven't heard that an effort has
been made to re-check -- it would probably need many volunteers
to cover the gamut. See SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS .

> I hope that now that we have apparently tracked this to a general
> MS implementation change which is unrelated to the restricted CAC
> hardware, that figuring out the OpenSSL compatibility issue will
> be a lot easier than when only USG employees and contractors with
> a CAC card could do the testing.
>
As Dr. Henson's replies indicate, there must be some other factor
here. Yes if it can be reproduced openly that should help.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

version number check in PreMasterSecret

Bin Lu-2
In reply to this post by Dr. Stephen Henson
While we are running test for client cert auth between the new IE version that supports TLS 1.1/1.2 and our server (running openssl 0.9.8d, only supports up to TLS1.0) which initiates server renegotiation for the client cert, we noticed that the IE sends the wrong version number in the PreMasterSecret in the renegotiation cycle. Then the server generates an alert and fails the handshaking.

However according to the RFC, it says the server should randomize the PreMasterSecret in case of error, rather than generate an alert. See below from the RFC:

   Note: The version number in the PreMasterSecret MUST be the version
         offered by the client in the ClientHello, not the version
         negotiated for the connection.  This feature is designed to
         prevent rollback attacks.  Unfortunately, many implementations
         use the negotiated version instead, and therefore checking the
         version number may lead to failure to interoperate with such
         incorrect client implementations.  Client implementations, MUST
         and Server implementations MAY, check the version number.  In
         practice, since the TLS handshake MACs prevent downgrade and no
         good attacks are known on those MACs, ambiguity is not
         considered a serious security risk.  Note that if servers
         choose to check the version number, they should randomize the
         PreMasterSecret in case of error, rather than generate an
         alert, in order to avoid variants on the Bleichenbacher attack.
         [KPR03]


   7.4.7.1. RSA Encrypted Premaster Secret Message

Does openSSL have a fix in that behavior in newer versions?

Thanks,
-binlu

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 01, 2012 5:26 AM
To: [hidden email]
Subject: Re: OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"

 
Since I can't reproduce this I'm wondering if the CAC cards introduce an additional element. I can see two possible reasons why they might:

1. Client authentication requires renegotiation if it is enabled on certain webpages and not across the whole site. The was a problem with version numbers in premaster secrets with IIS which has been fixed: I wonder if there is a similar one with MSIE which affects OpenSSL servers.

 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Loading...