[openssl-dev] Reminder: OpenSSL's EC private key encoding is broken

2015-03-24 Thread Annie Yousar
Dear all,
this should not have happened:

$ for i in  `seq 1 1000` ; do if [ x`openssl ecparam -genkey -name
prime256v1 -noout  key.pem; ls -l key.pem | sed '/ 227 /d'` !=  x ];
then echo; cat key.pem;else echo -n .; fi; done

-BEGIN EC PRIVATE KEY-
MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D
AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8
fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY
-END EC PRIVATE KEY-

...

Conforming to the standards the EC private key has always a fixed length,
defined by the group order.

Regards,
Ann.




___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3668] [PATCH] Don't use the cert list embedded in the OCSP response to build the trust chain

2015-03-24 Thread Stephen Henson via RT
On Fri Mar 20 13:20:07 2015, alessan...@ghedini.me wrote:

 Months have passed and I haven't received a reply yet (even worse, the
 recent
 obfuscation of the OCSP structures in 6ef869d7d0a9d made it impossible
 to
 workaround the issue as curl has been doing [0]), so I thought I'd add
 some more
 information to hopefully have this issue resolved.


Sorry for the delay in responding. Unfortunately I can't apply your patch
because it would break any applications which rely on the existing behaviour. I
have just committed a change which will concatenate the supplied certificates
with any internal ones. This should address your problem (the test program now
works) and retain compatibility.

Let me know of any problems.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

2015-03-24 Thread John Foley

Trying again w/o PGP...  :-)

Thanks for taking a look at this problem.  Regarding how to handle a 
failure in the session secret callback, the legacy logic would likely 
result in a bad record mac error because the master secrets on the 
client/server do not match.  It would be good to trigger an internal 
error to aid with troubleshooting.  Maybe something like:


SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
goto err;

It's debatable whether the alert needs to be sent to the server. Since 
this is an internal error, it should be safe to send the alert.  
Therefore, maybe you would actually want to do something like:


SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
al = SSL_AD_INTERNAL_ERROR;
goto f_err;



On 03/23/2015 09:17 PM, Emilia Käsper wrote:



On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com 
mailto:fol...@cisco.com wrote:


We've found a way to recreate the scenario using
s_client/s_server.  We're using the -no_ticket option on the
server.  Therefore, the ServerHello doesn't contain the session
ticket extension.  It also doesn't send the NewSessionTicket message.

To summarize the problem, when the client side is using
SSL_set_session_secret_cb() and including a valid ticket in the
ClintHello, then the logic in ssl3_get_server_hello() assumes the
server is doing session resumption.  This puts the client-side
state machine into the SSL3_ST_CR_FINISHED_A.  However, since the
server side is configured to not do resumption via the -no_ticket
option, the server continues with a normal handshake by sending
the Certificate message.  The client aborts the handshake when it
receives the Certificate message while in the
SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this
appears to be the addition of setting s-hit in the following code:

if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
SSL_CIPHER *pref_cipher = NULL;
s-session-master_key_length =
sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg)) {
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p + j);
s-hit = 1;
}
}

Why does the client-side now assume the server is doing session
resumption simply because the session secret callback facility is
being used?


Because a developer (me) introduced a bug. With OpenSSL client 
behaviour, peeking ahead is only required for EAP-FAST. I got rid of 
the peeking while tightening up the ChangeCipherSpec handling and in 
the process, got it wrong for EAP-FAST. Anyway, apologies, I see the 
problem and am working on a patch.


While we're at it, you may be able to help me with the following 
question: how should the client handle callback failure? The old code 
(pre my refactoring which introduced the bug) did this


#ifndef OPENSSL_NO_TLSEXT
/* check if we want to resume the session based on external pre-shared 
secret */
if (s-version = TLS1_VERSION  s-tls_session_secret_cb)
{
SSL_CIPHER *pref_cipher=NULL;
s-session-master_key_length=sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg))
{
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p+j);
}
}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia


From: openssl-dev [openssl-dev-boun...@openssl.org
mailto:openssl-dev-boun...@openssl.org] on behalf of Dr. Stephen
Henson [st...@openssl.org mailto:st...@openssl.org]
Sent: Thursday, March 19, 2015 11:49 AM
To: openssl-dev@openssl.org mailto:openssl-dev@openssl.org
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external
pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:


 If I do not send a sessionID in the clientHello but do send a valid
 sessionTicket extension, the server goes straight to
changeCipherSpec and
 the client generates an UnexpectedMessage alert.


Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: 

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

2015-03-24 Thread John Foley


binBBeWr6TKqL.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3758] [PATCH] fix malloc define typo

2015-03-24 Thread Matt Caswell via RT
Patch applied. Many thanks.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Bitlocker

2015-03-24 Thread Dirk-Willem van Gulik

 On 24 Mar 2015, at 10:07, Leon Brits le...@parsec.co.za wrote:
 
 Hi all,
  
 I have a PC which acts like a USB smartcard on which I have OpenSSLv1.0.1e to 
 simulate the smartcards crypto operations.
 I use it to sign/verify/encrypt/decrypt etc. and had no problem using Windows 
 to login and sign/verify emails for instance. Recently I tried bitlocker and 
 got the following error:
  
 Function call 'EVP_PKEY_decrypt()' failed! (error:0407106B:rsa 
 routines:RSA_padding_check_PKCS1_type_2:block type is not 02).
  
 The part in brackets was returned by OpenSSL.
  
 Can anybody shed some light on what possibly I can be doing wrong with 
 regards to the padding. I do implement PKCS1 and PSS. I’ve written our 
 CSP/KSP for this PC and as I said it works fine with other Windows 
 applications.
  
Not sure if this helps you - but I’ve seen the same issue with Windows SOAP 
requests which where signed with help from the TPM chip; and in that case it 
truly turned out that the padding was non standard (type 09).

HOWEVER - the error message has often misled me - as it is *also* triggered by 
a the length being wrong (flen != num-1(for the type 02 prefix)). So garbled 
length data can also trigger it (the note in the source that the flen is only 
used in no-padding mode may be a bit confusing/misleading).


Dw.___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Kurt Roeckx via RT
On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote:
 The short answer is that nobody has come up with comprehensive cross-platform 
 IPv6 support.  Fixing the apps isn't enough; how does a server listen on 
 IPv4, v6, both -- and make it work on our supported platforms? What should 
 the various BIO API's do?

Please note that I actually have a patch that does all that.  I
also said not to actually submit this patch.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Kurt Roeckx
On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote:
 The short answer is that nobody has come up with comprehensive cross-platform 
 IPv6 support.  Fixing the apps isn't enough; how does a server listen on 
 IPv4, v6, both -- and make it work on our supported platforms? What should 
 the various BIO API's do?

Please note that I actually have a patch that does all that.  I
also said not to actually submit this patch.


Kurt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] Using TLSv1.2

2015-03-24 Thread Андрей Даровских
I use the openssl library in the project and use client certificate
verification. When using protocol TLSv1.2 I have a problem with data
encryption, using the private key of the client certificate. This is due to
the fact that the certificate validation server selected encryption
algorithm that is not supported by the crypt used to encrypt the signature
on the client certificate (failure in method capi_rsa_sign of e_capi.c
file).
Now I have corrected the behavior as follows:
- the method ssl3_send_client_certificate after selecting a client
certificate makes cleaning pkeys [i].digest
- the method ssl_set_cert if pkeys [i] .digest not specified, specify it.

After that I worked with an application protocol TLSv1.2

Is this correct or am I wrong to fix the library using openssl?
Index: s3_clnt.c
===
--- s3_clnt.c   (revision 365595)
+++ s3_clnt.c   (working copy)
@@ -3276,6 +3276,13 @@
 }
 s-rwstate = SSL_NOTHING;
 if ((i == 1)  (pkey != NULL)  (x509 != NULL)) {
+if (SSL_USE_SIGALGS(s)) {
+/* Clear certificate digests and validity flags */
+for (i = 0; i  SSL_PKEY_NUM; i++) {
+s-cert-pkeys[i].digest = NULL;
+s-cert-pkeys[i].valid_flags = 0;
+}
+}
 s-state = SSL3_ST_CW_CERT_B;
 if (!SSL_use_certificate(s, x509) || !SSL_use_PrivateKey(s, pkey))
 i = 0;
Index: ssl_rsa.c
===
--- ssl_rsa.c   (revision 365595)
+++ ssl_rsa.c   (working copy)
@@ -222,6 +222,7 @@
 c-key = (c-pkeys[i]);
 
 c-valid = 0;
+
 return (1);
 }
 
@@ -430,6 +431,15 @@
 c-pkeys[i].x509 = x;
 c-key = (c-pkeys[i]);
 
+// set digest for certificate if it no set earlier
+if (c-pkeys[i].digest == NULL) {
+X509_ALGOR* alg = x-cert_info-signature;
+if (alg == NULL)
+c-pkeys[i].digest = EVP_sha1();
+else
+c-pkeys[i].digest = EVP_get_digestbyobj(alg-algorithm);
+}
+
 c-valid = 0;
 return (1);
 }
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] Bitlocker

2015-03-24 Thread Leon Brits
Hi all,

I have a PC which acts like a USB smartcard on which I have OpenSSLv1.0.1e to 
simulate the smartcards crypto operations.
I use it to sign/verify/encrypt/decrypt etc. and had no problem using Windows 
to login and sign/verify emails for instance. Recently I tried bitlocker and 
got the following error:

Function call 'EVP_PKEY_decrypt()' failed! (error:0407106B:rsa 
routines:RSA_padding_check_PKCS1_type_2:block type is not 02).

The part in brackets was returned by OpenSSL.

Can anybody shed some light on what possibly I can be doing wrong with regards 
to the padding. I do implement PKCS1 and PSS. I've written our CSP/KSP for this 
PC and as I said it works fine with other Windows applications.

Thanks for your time
LJB


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken

2015-03-24 Thread Douglas E Engert



On 3/24/2015 6:10 AM, Annie Yousar wrote:

Dear all,
this should not have happened:


The private key may have leading zero bytes, and the size of the BIGNUM is used
for the length of the octetstring rather then the field_len.
The length of the BIGNUM does not include any leading zeros.

Try the attached diff.




$ for i in  `seq 1 1000` ; do if [ x`openssl ecparam -genkey -name
prime256v1 -noout  key.pem; ls -l key.pem | sed '/ 227 /d'` !=  x ];
then echo; cat key.pem;else echo -n .; fi; done

-BEGIN EC PRIVATE KEY-
MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D
AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8
fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY
-END EC PRIVATE KEY-

...

Conforming to the standards the EC private key has always a fixed length,
defined by the group order.

Regards,
Ann.




___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



--

 Douglas E. Engert  deeng...@gmail.com

diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c
index 90de23b..b6aa7a5 100644
--- a/crypto/ec/ec_asn1.c
+++ b/crypto/ec/ec_asn1.c
@@ -1113,7 +1113,7 @@ int i2d_ECPrivateKey(EC_KEY *a, unsigned char **out)
 {
 int ret = 0, ok = 0;
 unsigned char *buffer = NULL;
-size_t buf_len = 0, tmp_len;
+size_t buf_len = 0, tmp_len, bn_len;
 EC_PRIVATEKEY *priv_key = NULL;
 
 if (a == NULL || a-group == NULL || a-priv_key == NULL ||
@@ -1129,18 +1129,33 @@ int i2d_ECPrivateKey(EC_KEY *a, unsigned char **out)
 
 priv_key-version = a-version;
 
-buf_len = (size_t)BN_num_bytes(a-priv_key);
+bn_len = (size_t)BN_num_bytes(a-priv_key);
+
+/* Octetstring may need leading zeros if BN is to short */
+
+buf_len = (EC_GROUP_get_degree(a-group) + 7) / 8;
+
+if (bn_len  buf_len) {
+ECerr(EC_F_I2D_ECPRIVATEKEY, ERR_R_BN_LIB);
+goto err;
+/* to get old behavior, set buf_len = bn_len */
+}
+
 buffer = OPENSSL_malloc(buf_len);
 if (buffer == NULL) {
 ECerr(EC_F_I2D_ECPRIVATEKEY, ERR_R_MALLOC_FAILURE);
 goto err;
 }
 
-if (!BN_bn2bin(a-priv_key, buffer)) {
+if (!BN_bn2bin(a-priv_key, buffer + buf_len - bn_len)) {
 ECerr(EC_F_I2D_ECPRIVATEKEY, ERR_R_BN_LIB);
 goto err;
 }
 
+if (buf_len - bn_len  0) {
+memset(buffer, 0, buf_len - bn_len);
+}
+
 if (!ASN1_OCTET_STRING_set(priv_key-privateKey, buffer, buf_len)) {
 ECerr(EC_F_I2D_ECPRIVATEKEY, ERR_R_ASN1_LIB);
 goto err;
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] ASN1_UTCTIME_cmp_time_t behavior changed from 0.9.8 to 1.0.2 ?

2015-03-24 Thread Susumu Sai
        time_t t;
        time(t);

        ASN1_TIME *tmptm = ASN1_TIME_new();
        X509_gmtime_adj(tmptm, 0);

        // ? With 0.9.8, the return value ret = 1 
        // ? With 1.0.2, the return value ret = -1
        int ret = ASN1_UTCTIME_cmp_time_t(tmptm, t);

0.9.8 and 1.0.2 return different values. Is this as expected?
Regards,
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] ASN1_UTCTIME_cmp_time_t behavior changed from 0.9.8 to 1.0.2 ?

2015-03-24 Thread Dr. Stephen Henson
On Tue, Mar 24, 2015, Susumu Sai wrote:

         time_t t;
         time(t);
 
         ASN1_TIME *tmptm = ASN1_TIME_new();
         X509_gmtime_adj(tmptm, 0);
 
         // ? With 0.9.8, the return value ret = 1 
         // ? With 1.0.2, the return value ret = -1
         int ret = ASN1_UTCTIME_cmp_time_t(tmptm, t);
 
 0.9.8 and 1.0.2 return different values. Is this as expected?

This is a bug in 1.0.2 which is fixed in 1.0.2a.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Short, Todd via RT
I was unaware of 2501. But that’s fine by me… however, why hasn’t 2051 been 
applied to the code?
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.

On Mar 24, 2015, at 4:14 PM, Quanah Gibson-Mount 
qua...@zimbra.commailto:qua...@zimbra.com wrote:

--On Tuesday, March 03, 2015 3:15 PM -0600 Short, Todd 
tsh...@akamai.commailto:tsh...@akamai.com wrote:

The previous patch file had two bugs due to a swapped argument and the
formatting changes (missing braces).


The attached is an updated patch.

Why did you open a new RT when 
http://rt.openssl.org/Ticket/Display.html?id=2051 already exists and has for 
ages?  I would suggest RT3717 be marked as a duplicate of 2051.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Quanah Gibson-Mount
--On Tuesday, March 24, 2015 9:29 PM + Short, Todd 
tsh...@akamai.com wrote:



I was unaware of 2501. But that's fine by me… however, why hasn't
2051 been applied to the code?


People have been asking this question for years.

https://lwn.net/Articles/486369/

http://openssl.6102.n7.nabble.com/Openssl-IPv6-Support-td54588.html

Here's an even *older* RT from 2006: 
http://rt.openssl.org/Ticket/Display.html?id=1365user=guestpass=guest


There's never been any sort of real substantive answer as to why getting 
IPv6 support in has taken almost a decade, when people have constantly 
supplied patches for it.  Supposedly it was going to go into 1.0.2.



--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Quanah Gibson-Mount via RT
--On Tuesday, March 24, 2015 9:29 PM + Short, Todd 
tsh...@akamai.com wrote:

 I was unaware of 2501. But that's fine by me… however, why hasn't
 2051 been applied to the code?

People have been asking this question for years.

https://lwn.net/Articles/486369/

http://openssl.6102.n7.nabble.com/Openssl-IPv6-Support-td54588.html

Here's an even *older* RT from 2006: 
http://rt.openssl.org/Ticket/Display.html?id=1365user=guestpass=guest

There's never been any sort of real substantive answer as to why getting 
IPv6 support in has taken almost a decade, when people have constantly 
supplied patches for it.  Supposedly it was going to go into 1.0.2.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Quanah Gibson-Mount
--On Tuesday, March 03, 2015 3:15 PM -0600 Short, Todd 
tsh...@akamai.com wrote:



The previous patch file had two bugs due to a swapped argument and the
formatting changes (missing braces).


The attached is an updated patch.


Why did you open a new RT when 
http://rt.openssl.org/Ticket/Display.html?id=2051 already exists and has 
for ages?  I would suggest RT3717 be marked as a duplicate of 2051.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Short, Todd
I was unaware of 2501. But that’s fine by me… however, why hasn’t 2051 been 
applied to the code?
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.

On Mar 24, 2015, at 4:14 PM, Quanah Gibson-Mount 
qua...@zimbra.commailto:qua...@zimbra.com wrote:

--On Tuesday, March 03, 2015 3:15 PM -0600 Short, Todd 
tsh...@akamai.commailto:tsh...@akamai.com wrote:

The previous patch file had two bugs due to a swapped argument and the
formatting changes (missing braces).


The attached is an updated patch.

Why did you open a new RT when 
http://rt.openssl.org/Ticket/Display.html?id=2051 already exists and has for 
ages?  I would suggest RT3717 be marked as a duplicate of 2051.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Quanah Gibson-Mount via RT
--On Tuesday, March 03, 2015 3:15 PM -0600 Short, Todd 
tsh...@akamai.com wrote:

 The previous patch file had two bugs due to a swapped argument and the
 formatting changes (missing braces).


 The attached is an updated patch.

Why did you open a new RT when 
http://rt.openssl.org/Ticket/Display.html?id=2051 already exists and has 
for ages?  I would suggest RT3717 be marked as a duplicate of 2051.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Salz, Rich via RT
The short answer is that nobody has come up with comprehensive cross-platform 
IPv6 support.  Fixing the apps isn't enough; how does a server listen on IPv4, 
v6, both -- and make it work on our supported platforms? What should the 
various BIO API's do?

Looking forward to diff's.
 


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev