Hi all,
I'm compiling openssl-0.9.8p on Windows and find a strange thing in
crypto/err/err_all.c , for example ,
the original declaration in crypto/store/store.h(line 390) is
...
X509_NAME *STORE_ATTR_INFO_get0_dn(STORE_ATTR_INFO *attrs,
STORE_ATTR_TYPES code);
..
after preprocessing of crypto/err/
On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote:
> I can confirm that removing the "no-ssl2" part gets me a TLS
> instead of SSLv3 connection.
The problem seems to be this code in s_client.c:
#if !defined(OPENSSL_NO_SSL2) && !defined(OPENSSL_NO_SSL3)
meth=SSLv23_client_m
On Sun, Mar 18, 2012 at 12:20:48AM +0100, Kurt Roeckx via RT wrote:
> On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT
> wrote:
> > On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
> >
> > >> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
> > >>
> > >>
> > >> I captur
ping?
this should be trivial.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager major
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT wrote:
> On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
>
> >> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
> >>
> >>
> >> I captured the handshake (attached), and it seems the client
> >> advertises TLS 1.2. Could i
Understood. I asked in part because I want to minimize the
number/scope of modifications so that the change letter validation is
viable and straightforward; and, I asked out of curiosity.
Kevin
On Sat, Mar 17, 2012 at 12:26 PM, Andy Polyakov wrote:
>> Is incore part of the validation, or is it li
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
>> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
>>
>>
>> I captured the handshake (attached), and it seems the client
>> advertises TLS 1.2. Could it be that the fallback is on the lowest
>> supported version rather than the next available?
>
> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
>
>
> I captured the handshake (attached), and it seems the client advertises
> TLS 1.2. Could it be that the fallback is on the lowest supported
> version rather than the next available?
>
That's strange. I tried OpenSSL 1.0.0h server (which supp
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote:
> The EC codes does need a bit of revising, that is one of its many quirks.
> I'm trying to work out though how that client ends up producing that
> condition. The only way I can think s_server with those command line
> options could end up usi
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
> > modexp512-x86_64.s ends here:
> > | #
> > | # X2 = Xh * M2 + Xl
> > | # do first part (X2 = Xh * M2)
> > | addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
> > | #Xh is actually { [rdi+8*1], rbp }
> > |
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
> > modexp512-x86_64.s ends here:
> > | #
> > | # X2 = Xh * M2 + Xl
> > | # do first part (X2 = Xh * M2)
> > | addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
> > | #Xh is actually { [rdi+8*1], rbp }
> > |
On Sat, Mar 17, 2012 at 3:53 PM, Stephen Henson via RT wrote:
> > My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
> > 1.0 or later. According to it: "This document describes additions to TLS
> > to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
> > Version 1.
> Is incore part of the validation, or is it like fipsld - allowed to be
> modified as needed without invalidating FIPS certification?
It shouldn't void certification, no. But why is it concern for you? You
have to aim for change letter and therefore there is window for
including even this modific
> modexp512-x86_64.s ends here:
> | #
> | # X2 = Xh * M2 + Xl
> | # do first part (X2 = Xh * M2)
> | addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
> | #Xh is actually { [rdi+8*1], rbp }
> | addq$64,%rsi# rsi -> M2
> | leaq296(%rsp),%rcx# rcx -> pX2 ; 641
> Building with darwin-x86_64-cc.
>
> Error is:
>
> paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64
Sounds like bug in assembler, as it's not absolute address there. What
does 'as -v' print on your system? I can't reproduce the problem with
"Apple Inc version cctools-822
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote:
> The EC codes does need a bit of revising, that is one of its many quirks.
> I'm trying to work out though how that client ends up producing that
> condition. The only way I can think s_server with those command line
> options could end up usi
The documentation doesn't reflect current behaviour. The "type"
parameter to DSA_sign and DSA_verify is currently ignored, it should
arguably check the length is consistent with the passed digest type.
The actual algorithm implementation is OK though. The supplied digest
will be truncated if it ex
> [fol...@cisco.com - Sat Mar 17 14:55:45 2012]:
>
> Using "openssl s_server" as the application with libcrypto 1.0.1, it
> appears the TLS 1.2 behavior may not be compliant with RFC 5246. Page
> 49 of RFC 5246 states:
>
> If the client provided a "signature_algorithms" extension, then all
>
> [n...@gnutls.org - Sat Mar 17 14:57:31 2012]:
>
> Hello,
> My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
> 1.0 or later. According to it: "This document describes additions to TLS
> to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
> Version 1.1 [3]. In p
Hello,
My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
1.0 or later. According to it: "This document describes additions to TLS
to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
Version 1.1 [3]. In particular, it defines...".
So it seems that SSL 3.0 shouldn'
Hi,
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi -> M2
| leaq296(%rsp),%rcx# rcx -> pX2 ; 641 bits, 11 qwo
Building with darwin-x86_64-cc.
Error is:
paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64
I have attached my diff which fixes it.
Please let me know if you need further information.
Regards,
Jeremiah Rothschild
Systems Administrator
Franz Inc.
diff -r -u openssl-1.0.
22 matches
Mail list logo