Re: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit

2015-11-02 Thread Steve Marquess
On 11/02/2015 05:57 PM, Natan Drozd wrote: > > > Hi > Does openssl supports/has a supported version for iOS 64 bit? >From the subject line I think you meant "does the OpenSSL FIPS Object Module" support iOS 64 bits. Take a look at Table 2 of the Security Policy, platforms 103/104: http://csr

[openssl-dev] [openssl.org #4120] CertificateStatus message is optional

2015-11-02 Thread David Benjamin via RT
It seems unlikely I'll be getting around to doing another newsletter, but while I'm reporting bugs, here's another that came to mind: RFC 6066 is somewhat obnoxious and allows the server to decline to send CertificateStatus even after negotiating the extension. https://tools.ietf.org/html/rfc6066

[openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

2015-11-02 Thread David Benjamin via RT
Hey folks, We found a small DTLS bug while writing some tests. I think it affects 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about master. I'm unfamiliar with the new state machine mechanism.) In DTLS, each ClientHello is supposed to reset the handshake hash (in case of Hel

Re: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit

2015-11-02 Thread Natan Drozd
Hi Does openssl supports/has a supported version for iOS 64 bit? Thank You, Natan Drozd -- ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4118] Failed test 80 with OpenSSL 1.1.0-dev on NetBSD 6_Stable

2015-11-02 Thread yancm via RT
Recently I started getting a test that required PEM key interactive input. I used "ABC123". I am running the test suite as a non-root user. Failure is below: ../test/recipes/80-test_ca.t .. Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ../test/recipes/80-test_ca.t ..

[openssl-dev] 1.0.2e release?

2015-11-02 Thread Short, Todd
openssl-dev: It’s been almost 4 months, and ~127 commits since 1.0.2d went out the door. Are there plans for an upcoming 1.0.2e release? Thanks, -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." _

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-11-02 Thread Albe Laurenz via RT
Matt Caswell wrote: > On 02/11/15 10:16, Albe Laurenz via RT wrote: >> If interleaved application data are only allowed >> a) before Change Cipher Spec >> b) during a renegotiation, i.e., when the connection is encrypted >> >> your second example and similar exploits would not work, because the >>

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-11-02 Thread Albe Laurenz
Matt Caswell wrote: > On 02/11/15 10:16, Albe Laurenz via RT wrote: >> If interleaved application data are only allowed >> a) before Change Cipher Spec >> b) during a renegotiation, i.e., when the connection is encrypted >> >> your second example and similar exploits would not work, because the >>

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-11-02 Thread Matt Caswell via RT
On 02/11/15 10:16, Albe Laurenz via RT wrote: > Hubert Kario wrote: >> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >>> My concern though is broader than this specific case. I have given two >>> *examples* of exploits that we may open ourselves up to if we attempt >>> to process

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-11-02 Thread Albe Laurenz via RT
Hubert Kario wrote: > On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >> My concern though is broader than this specific case. I have given two >> *examples* of exploits that we may open ourselves up to if we attempt >> to process this application data without some fairly significant

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-11-02 Thread Albe Laurenz
Hubert Kario wrote: > On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >> My concern though is broader than this specific case. I have given two >> *examples* of exploits that we may open ourselves up to if we attempt >> to process this application data without some fairly significant