Re: [openssl-dev] [openssl.org #3976] Bug report
My feeling is that you should not be copying an EVP if data is NULL and that the earlier null checks are erroneous. But I could be wrong. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3976] Bug report
The cryptographic engineering team at Blue Coat systems is conducting a review
of OpenSSL and have found the following minor bug. We would appreciate your
consideration.
Observe the following lines in evp_enc.c:
if (in->cipher_data && in->cipher->ctx_size) {
out->cipher_data = OPENSSL_malloc(in->cipher->ctx_size);
if (!out->cipher_data) {
EVPerr(EVP_F_EVP_CIPHER_CTX_COPY, ERR_R_MALLOC_FAILURE);
return 0;
}
memcpy(out->cipher_data, in->cipher_data, in->cipher->ctx_size);
}
if (in->cipher->flags & EVP_CIPH_CUSTOM_COPY)
return in->cipher->ctrl((EVP_CIPHER_CTX *)in, EVP_CTRL_COPY, 0, out);
Note that in->cipher data is checked for NULL, which implies that
in->cipher_data can be NULL. Now, take a look at function ads_ccm_ctrl, which
is what in->cipher_ctrl points to:
static int aes_ccm_ctrl(EVP_CIPHER_CTX *c, int type, int arg, void *ptr)
{
EVP_AES_CCM_CTX *cctx = c->cipher_data;
switch (type) {
case EVP_CTRL_INIT:
cctx->key_set = 0;
cctx->iv_set = 0;
cctx->L = 8;
cctx->M = 12;
cctx->tag_set = 0;
cctx->len_set = 0;
return 1;
Note that c->cipher_data has been dereferenced, even though it may be NULL.
Thanks,
Harold Stuart
Senior Staff Engineer
Blue Coat Systems, Inc.
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 11:31:08PM +, p...@securecottage.com wrote: > I have checked through the key generation code of the openssl ssl code. Not carefully enough... > I > hacked it to report the greatest common divisor of p-1 and q-1. I then ran > 100 key generations. It only had greatest common divisors of 2, 4 , 8, and > 16. There were no other primes reported besides small powers of 2. The reason is that all the pseudo-primes generated for testing are sieved to avoid numbers that are congruent to either 0 or 1 mod p for each of the first 2048 primes other than 2 (2 is avoided by forcing the low bit to 1). Thus any odd factor of (p-1) or (q-1) is necessarily larger than the 2048th prime or 17863. To see an appreciable chance of such a common factor you need O(2) trials. While a check to avoid gcd(p-1, q-1) > 2 is not too expensive, it is not clear that it is worth the trouble. Perhaps it should be done anyway, just because we can, but I am not convinced. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
I hear you. Let me discuss this with my colleagues, and get back to the list if they see good reasons to add this check. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Bill Cox Sent: Friday, July 31, 2015 20:09 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] common factors in (p-1) and (q-1) On Fri, Jul 31, 2015 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL wrote: I think adding the recommended check would be beneficial. Considering the frequency of key generation, performance impact shouldn't matter all that much. Samuel's argument above is one I've heard before from Thomas Porin, which is why I was not recommending we do or do not do this check. I was just estimating the performance hit. I personally have not gone over the paper Samuel linked to other than to read the abstract. However, assuming the paper's claims are correct, which seems to be backed up by these two fine cryptography experts, I think the additional check would do more harm than good. Bill smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > I think adding the recommended check would be beneficial. Considering the > frequency of key generation, performance impact shouldn't matter all that > much. > Samuel's argument above is one I've heard before from Thomas Porin, which is why I was not recommending we do or do not do this check. I was just estimating the performance hit. I personally have not gone over the paper Samuel linked to other than to read the abstract. However, assuming the paper's claims are correct, which seems to be backed up by these two fine cryptography experts, I think the additional check would do more harm than good. Bill ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
I think adding the recommended check would be beneficial. Considering the frequency of key generation, performance impact shouldn't matter all that much. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: p...@securecottage.com Sent: Friday, July 31, 2015 19:31 To: mancha Reply To: openssl-dev@openssl.org Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] common factors in (p-1) and (q-1) Hi Mancha, Since p*q-1==(p-1)*(q-1)+(p-1)+q-1) any prime that divides (p-1) and (q-1) will divide all 4 of the terms in the definition of p*q-1. Thus it will be a common factor in the totient. I have checked through the key generation code of the openssl ssl code. I hacked it to report the greatest common divisor of p-1 and q-1. I then ran 100 key generations. It only had greatest common divisors of 2, 4 , 8, and 16. There were no other primes reported besides small powers of 2. So there doesn't seem to be a practical problem with common divisors in the openssl code. Still, I think this is a theoretical problem. There should be a gcd(p-1,q-1)>16 check for the two primes in key generation. Paul Quoting mancha : > On Fri, Jul 31, 2015 at 02:36:03AM +, p...@securecottage.com wrote: >> >> Hi there, >> >> I have looked at the RSA protocol a bit and have concluded that >> >> 1) common factors in (p-1) and (q-1) are also in the factorisation of >> (p*q-1). 2) by factoring (p*q-1) you can come up with candidates for >> squares in the totient. 3) you can also come up with d mod >> commonfactor^2 if there is a common factor. >> >> the math is shown in my wikipedia users page math blog at: >> >> https://en.wikipedia.org/wiki/User:Endo999#The_Bad_Stuff_That_Happens_When_There_Are_Common_Factors_Between_.28P-1.29_and_.28Q-1.29 > > [SNIP] > > Hi. How are you finding a common factor f such that f|(p-1) and f|(q-1)? > > Thanks. > > --mancha > > -- https://twitter.com/mancha140 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On 31-07-2015 22:03, Viktor Dukhovni wrote: > Is finding sufficiently large factors a tractable problem? p-1 will usually have a large prime factor. But for q-1 to have the same prime factor is highly unlikely. The probability that GCD(n1, n2) = d for random n1, n2 is 6/(d^2 pi^2). For RSA-1024 we need at least 256 bits of d leaked to factor n using Coppersmith-style attacks. For that to happen, we need a common factor of at least 128 bits to exist (to leak d mod f^2). This is significantly less likely than Miller-Rabin plain failing (with probability ~2^-80) and selecting a non-prime p or q. Regarding strong primes and their utility, the Rivest-Silverman paper is still worth reading: https://people.csail.mit.edu/rivest/pubs/RS01.version-1999-11-22.pdf ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
Hi Mancha, Since p*q-1==(p-1)*(q-1)+(p-1)+q-1) any prime that divides (p-1) and (q-1) will divide all 4 of the terms in the definition of p*q-1. Thus it will be a common factor in the totient. I have checked through the key generation code of the openssl ssl code. I hacked it to report the greatest common divisor of p-1 and q-1. I then ran 100 key generations. It only had greatest common divisors of 2, 4 , 8, and 16. There were no other primes reported besides small powers of 2. So there doesn't seem to be a practical problem with common divisors in the openssl code. Still, I think this is a theoretical problem. There should be a gcd(p-1,q-1)>16 check for the two primes in key generation. Paul Quoting mancha : On Fri, Jul 31, 2015 at 02:36:03AM +, p...@securecottage.com wrote: Hi there, I have looked at the RSA protocol a bit and have concluded that 1) common factors in (p-1) and (q-1) are also in the factorisation of (p*q-1). 2) by factoring (p*q-1) you can come up with candidates for squares in the totient. 3) you can also come up with d mod commonfactor^2 if there is a common factor. the math is shown in my wikipedia users page math blog at: https://en.wikipedia.org/wiki/User:Endo999#The_Bad_Stuff_That_Happens_When_There_Are_Common_Factors_Between_.28P-1.29_and_.28Q-1.29 [SNIP] Hi. How are you finding a common factor f such that f|(p-1) and f|(q-1)? Thanks. --mancha -- https://twitter.com/mancha140 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 01:42:01PM -0700, Bill Cox wrote: > You are correct, or at least very close. I was testing for GCD(p-1, q-1) > == 4, when I should have been testing for GCD(p-1, q-1) == 2, since p-1 and > q-1 are known to be even. Fixing that, I see that the probability of > having GCD(p-1, q-1) == 2 for random odd numbers is a bit over 60% in the > python runs. This will result most likely in a bit less a 2X runtime > penalty for determining the primes. There's no need for that, just a priori force at least one of then to be 3 mod 4. Then the largest common even factor is necessarily 2. I still see little reason to bother though. My example demostrates a GCD of 28559 * 2 (almost 16 bits), so we can compute d = 1/e mod phi(m) modulo an ~31 bit number, but d is a 1024-bit number, knowing it mod an ~31 bit number does not seem particularly useful. Common factors with considerably more bits are exponentially (correct usage for once) rare. Does this "leak" warrant remediation? How would the attacker know whether any factors of (n-1) are or are not in fact common factos of (p-1) and (q-1) if p and q remain unknown? Is finding sufficiently large factors a tractable problem? -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 12:35 PM, mancha wrote: > If so, here's my quick & dirty back-of-envelope calculation (mod bound) > for the probability the gcd of two randomly chosen integers x,y is at > most k: > > k p(gcd(x,y)<=k) > - -- > 1 60.79% > 2 75.99% > 3 82.75% > 4 86.55% > 5 88.98% > 6 90.67% > 7 91.91% > 8 92.86% > 9 93.61% > 10 94.21% > > As can be seen, the probability is quite high the gcd will be small so > (p-1)(q-1) ~ lcm((p-1)(q-1)) removing the above benefit. > > But it's the end of the week and the neurons need respite so please let > me know if I'm missing something. > You are correct, or at least very close. I was testing for GCD(p-1, q-1) == 4, when I should have been testing for GCD(p-1, q-1) == 2, since p-1 and q-1 are known to be even. Fixing that, I see that the probability of having GCD(p-1, q-1) == 2 for random odd numbers is a bit over 60% in the python runs. This will result most likely in a bit less a 2X runtime penalty for determining the primes. Bill ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method
On 31/07/15 20:15, Matt Caswell wrote:
>
>
> On 31/07/15 18:51, Jouni Malinen wrote:
>> This is the relevant part of that commit:
>>
>> @@ -1602,13 +1585,13 @@ int ssl3_send_server_hello(SSL *s)
>>
>> if (s->state == SSL3_ST_SW_SRVR_HELLO_A) {
>> buf = (unsigned char *)s->init_buf->data;
>> -#ifdef OPENSSL_NO_TLSEXT
>> +
>> p = s->s3->server_random;
>> if (ssl_fill_hello_random(s, 1, p, SSL3_RANDOM_SIZE) <= 0) {
>> s->state = SSL_ST_ERR;
>> return -1;
>> }
>> -#endif
>> +
>> /* Do the message type and length last */
>> d = p = ssl_handshake_start(s);
>>
>>
>> That ssl_fill_hello_random() call needs to be deleted to fix this issue.
>> Based on a quick test, that does indeed fix the EAP-FAST server issue I
>> saw.
>>
>
> Duhhh. Your email reminded me that I already fixed this a little while
> ago (actually I remembered just after I implemented the fix for a second
> time!). It got stuck in our review queue and I forgot about it. I've
> just pinged it so hopefully it will become unstuck and I can get this
> committed.
https://github.com/openssl/openssl/commit/e1e088ec7f2f33c4c4ad31312d62c536441d4358
Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote: > Cool observation. From running a bit of Python code, it looks like > the probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at > least for random numbers between 2048 and 4096 bits long. It looks > like putting in a GCD(p-1, q-1) check will slow down finding suitable > p and q by around a factor of 6.5. > > I am not saying OpenSSL should or should not do this check, but > hopefully making that decision is easier knowing the runtime penalty. To clarify, the worry is that lcm((p-1),(q-1)) << (p-1)(q-1) thus making the computation of d=1/e (mod lcm((p-1),(q-1))) comparatively easier? If so, here's my quick & dirty back-of-envelope calculation (mod bound) for the probability the gcd of two randomly chosen integers x,y is at most k: k p(gcd(x,y)<=k) - -- 1 60.79% 2 75.99% 3 82.75% 4 86.55% 5 88.98% 6 90.67% 7 91.91% 8 92.86% 9 93.61% 10 94.21% As can be seen, the probability is quite high the gcd will be small so (p-1)(q-1) ~ lcm((p-1)(q-1)) removing the above benefit. But it's the end of the week and the neurons need respite so please let me know if I'm missing something. --mancha -- https://twitter.com/mancha140 pgpuPoMiAQmxY.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method
On 31/07/15 18:51, Jouni Malinen wrote:
> This is the relevant part of that commit:
>
> @@ -1602,13 +1585,13 @@ int ssl3_send_server_hello(SSL *s)
>
> if (s->state == SSL3_ST_SW_SRVR_HELLO_A) {
> buf = (unsigned char *)s->init_buf->data;
> -#ifdef OPENSSL_NO_TLSEXT
> +
> p = s->s3->server_random;
> if (ssl_fill_hello_random(s, 1, p, SSL3_RANDOM_SIZE) <= 0) {
> s->state = SSL_ST_ERR;
> return -1;
> }
> -#endif
> +
> /* Do the message type and length last */
> d = p = ssl_handshake_start(s);
>
>
> That ssl_fill_hello_random() call needs to be deleted to fix this issue.
> Based on a quick test, that does indeed fix the EAP-FAST server issue I
> saw.
>
Duhhh. Your email reminded me that I already fixed this a little while
ago (actually I remembered just after I implemented the fix for a second
time!). It got stuck in our review queue and I forgot about it. I've
just pinged it so hopefully it will become unstuck and I can get this
committed.
Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote: > Cool observation. From running a bit of Python code, it looks like the > probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at least for > random numbers between 2048 and 4096 bits long. It looks like putting in a > GCD(p-1, q-1) check will slow down finding suitable p and q by around a > factor of 6.5. A smaller slow-down would be incurred one were to restrict both of p,q to 3 mod 4. In that case 2 would be the largest common even factor of (p-1) and (q-1), and any appreciably large common odd factor (necessarily above 17863 due to how each of p/q is chosen) would be very rare. Is there a good argument for adding the gcd test? How big does the common factor have to be for any information it might provide to be substantially useful in finding 1/e mod phi(m)? The larger the common factor is, the smaller the probability of p-1 and q-1 sharing it (for a given sufficiently large prime factor "r" of (p-1), the probability of (q-1) also having that factor is 1/(r-1)). If say "r" needs be 80 bits long to be useful in attacking RSA 1024, then only ~1 in 2^80 (p-1,q-1) pairs will have such a common factor, which is sufficiently rare not warrant any attention. Also one still needs to be able to fully factor (n-1). After tens of thousands of trials, I managed to generate a (p,q,n) triple with a 1024-bit modulus n in which (p-1,q-1) have a common odd factor. n = 123727085863382195696899362818055010267368591819174730632443285012648773223152448218495408371737254282531468855140111723936275062312943433684139231097953508685462994307654703316031424869371422426773001891452680576333954733056995016189880381373567072504551999849596021790801362257131899242011337424119163152403 e = F_4 = 65537 gcd(p-1,q-1) = 2 * 28559 What can the OP tell us about d, p or q? Can anyone produce a full factorization of n - 1? -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
Cool observation. From running a bit of Python code, it looks like the probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at least for random numbers between 2048 and 4096 bits long. It looks like putting in a GCD(p-1, q-1) check will slow down finding suitable p and q by around a factor of 6.5. I am not saying OpenSSL should or should not do this check, but hopefully making that decision is easier knowing the runtime penalty. Bill ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
On Fri, Jul 31, 2015 at 12:29 PM, Hanno Böck wrote: > "Salz, Rich" wrote: > > > Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some > > more details. > > > > Summary: Moving to Apache 2, CLA's coming, it will take time. > > This is a huge step if it works (I leave it up to the lawyers to decide > if it will), but I want to question whether Apache License is really a > wise move. [snip] In the spirit of making OpenSSL as useful as possible for everyone I > would consider a permissive license that's more compatible (e.g. MIT) a > wiser choice. > I agree 100%. What is wrong with the ISC-style license that LibreSSL and BoringSSL have been using to share code? Why not use that same license for new code? The ability to share code between these projects is hugely valuable, especially when it comes to getting security problems fixed in a timely and secure manner. Also, I question the need for people to sign a CLA to contribute to OpenSSL. OpenSSL has been very successful for decades without a CLA requirement. Lots of other projects are extremely successful without a CLA. A CLA seems unnecessary. Cheers, Brian [1] https://www.imperialviolet.org/2014/06/20/boringssl.html (end of document) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
+1 Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Hanno Böck Sent: Friday, July 31, 2015 12:55 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] We're working on license changes Hi, On Fri, 31 Jul 2015 14:37:30 + "Salz, Rich" wrote: > Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some > more details. > > Summary: Moving to Apache 2, CLA's coming, it will take time. This is a huge step if it works (I leave it up to the lawyers to decide if it will), but I want to question whether Apache License is really a wise move. AFAIK there has been work done to make the apache license compatible with the GPL, both with changes in the APache license and the GPL, but this only applies to the GPL 3. Whether one likes that or not, there is still a lot of GPL2-only code out there and that's unlikely to change because for some projects it's close to impossible to change the license due to the number of contributors. Just to give a very concrete example: Apache 2 licensing would mean that the linux kernel could not take code from OpenSSL. In the spirit of making OpenSSL as useful as possible for everyone I would consider a permissive license that's more compatible (e.g. MIT) a wiser choice. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method
On Thu, Jul 30, 2015 at 11:00:45AM +0100, Matt Caswell wrote:
> On 28/07/15 15:09, Jouni Malinen wrote:
> > The remaining issue for EAP-FAST server is in the
> > SSL_set_session_secret_cb() callback not having access to the correct
> > server_random through SSL_get_server_random().
> Is this still a problem? From looking at the code it seems to me that
> the server random is set prior to calling the callback:
It is a problem with the current master branch snapshot, but not with
older versions, i.e., a regression of some sort..
> /*
> * Check if we want to use external pre-shared secret for this handshake
> * for not reused session only. We need to generate server_random before
> * calling tls_session_secret_cb in order to allow SessionTicket
> * processing to use it in key derivation.
> */
> {
> unsigned char *pos;
> pos = s->s3->server_random;
> if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
This is indeed the server_random I see in the tls_session_secret_cb, but
that is not the server_random that gets used in the negotiation..
> Checking the commit logs this seems to have been put in by this commit
> responding to one of your tickets!
>
> commit 12bf56c017a34bd0d5fc6d817564ae49d0a9e861
It was indeed and that commit worked.. Please note that it uses #ifdef
OPENSSL_NO_TLSEXT to avoid having ssl3_send_server_hello() override the
previously selected server_random.
> You seem to imply that you can get the server_random through
> ssl->s3->server_random but not through SSL_get_server_random(). Looking
> at the code I can't see an obvious reason why that would be the case.
> Here is SSL_get_server_random():
>
> size_t SSL_get_server_random(const SSL *ssl, unsigned char *out, size_t
> outlen)
> {
> if (outlen == 0)
> return sizeof(ssl->s3->server_random);
> if (outlen > sizeof(ssl->s3->server_random))
> outlen = sizeof(ssl->s3->server_random);
> memcpy(out, ssl->s3->server_random, outlen);
> return outlen;
> }
I had not checked what this does, but yes, that's indeed identical to
the mechanism I use with older OpenSSL version. In other words, the
issue is in ssl3_send_server_hello().
It looks like commit e481f9b90b164fd1053015d1c4e0a0d92076d7a8
("Remove support for OPENSSL_NO_TLSEXT") broke this. It is deleting
number of "#ifndef OPENSSL_NO_TLSEXT" lines correctly, but it is also
deleting one "#ifdef OPENSSL_NO_TLSEXT" without removing the block of
code that should have also been removed from ssl3_send_server_hello().
Because of that, server_random gets replaced after the call to
tls_session_secret_cb which breaks the EAP-FAST use case.
This is the relevant part of that commit:
@@ -1602,13 +1585,13 @@ int ssl3_send_server_hello(SSL *s)
if (s->state == SSL3_ST_SW_SRVR_HELLO_A) {
buf = (unsigned char *)s->init_buf->data;
-#ifdef OPENSSL_NO_TLSEXT
+
p = s->s3->server_random;
if (ssl_fill_hello_random(s, 1, p, SSL3_RANDOM_SIZE) <= 0) {
s->state = SSL_ST_ERR;
return -1;
}
-#endif
+
/* Do the message type and length last */
d = p = ssl_handshake_start(s);
That ssl_fill_hello_random() call needs to be deleted to fix this issue.
Based on a quick test, that does indeed fix the EAP-FAST server issue I
saw.
--
Jouni MalinenPGP id EFC895FA
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3975] The CMS encrypt command uses the wrong ASN.1 encoding for the AES-GCM algorithm parameter.
When using 'openssl cms -encrypt -aes-256-gcm' the algorithm generated is
encoded as:
SEQUENCE(2 elem)
OBJECT IDENTIFIER2.16.840.1.101.3.4.1.46
OCTET STRING(12 byte)
But RFC 5084 (Using AES-CCM and AES-GCM Authenticated Encryption in the
Cryptographic Message Syntax (CMS)) specifies the algorithm parameters as:
GCMParameters ::= SEQUENCE {
aes-nonceOCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
So the openssl version is missing the SEQUENCE tag.
Version tested: openssl 1.0.2d on linux x86_64
Example:
openssl cms -encrypt -in message.txt -out encrypted-openssl-aes-256-gcm.msg
-recip user1_no_cn.pem -aes-256-gcm
encrypted-openssl-aes-256-gcm.msg
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3974] The IV used by the 'openssl cms -encrypt -aes-256-gcm' command is not random (all zeroes).
On Fri, Jul 31, 2015 at 05:35:51PM +, Laetitia Baudoin via RT wrote: > When encrypting using the 'openssl cms -encrypt -aes-256-gcm' command an > all zero IV is used, this breaks any guarantees provided by the GCM > mode (see NIST Special Publication 800-38D). > https://mta.openssl.org/pipermail/openssl-dev/2015-April/001177.html > - If AES-GCM is not supported by the 'openssl cms' command (there is no > clear RFC for it when generating enveloped data, RFC 5084 is for > authenticated enveloped data) the command should show an error. Yes, it should return an error. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3974] The IV used by the 'openssl cms -encrypt -aes-256-gcm' command is not random (all zeroes).
When encrypting using the 'openssl cms -encrypt -aes-256-gcm' command an all zero IV is used, this breaks any guarantees provided by the GCM mode (see NIST Special Publication 800-38D). Version tested: openssl 1.0.2d on linux x86_64. Example: openssl cms -encrypt -in message.txt -out encrypted-openssl-aes-256-gcm.msg -recip user1_no_cn.pem -aes-256-gcm When looking at the ASN.1 for the contentEncryptionAlgorithm we get: SEQUENCE(2 elem) OBJECT IDENTIFIER2.16.840.1.101.3.4.1.46 OCTET STRING(12 byte) <-- This is the IV Expectation: - If AES-GCM is not supported by the 'openssl cms' command (there is no clear RFC for it when generating enveloped data, RFC 5084 is for authenticated enveloped data) the command should show an error. - If AES-GCM is supported it should generate a random IV encrypted-openssl-aes-256-gcm.msg Description: Binary data ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2464] TLS-RSA-PSK support
On Fri, Jul 31, 2015 at 07:24:15PM +0200, Hubert Kario wrote: > > Question, should we really be adding new RC4 or new 3DES ciphersuites? > > Both ciphers are rather obsolete now. And we even have an RFC that > > "bans" RC4. While I have been known to resist potentially premature > > removal of *existing* RC4 support, I am certainly not a fan of RC4 > > and see no reason to add more RC4 to OpenSSL. > > those are PSK ciphers, unless you set up PSK they won't be advertised at all, > adding support for them has minimal impact on Internet use (be it port 443 or > otherwise) of RC4 and 3DES > > and for people that actually need this support, it's better that they use > OpenSSL than a home-cooked solution by an intern I know all that, but do they in fact need RC4 or 3DES, or are we just putting them in because they have code-point assignments in the RFC? > > I am not even sure that adding Camellia is a net win, ideally AES > > and (soonish) ChaCha20 are enough. > > Camellia is the recommended backup cipher by ENISA, rightfully so Fine. > > One might similarly question the longevity of the new CBC suites, > > TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be > > used for session resumption in 1.3). > > I give them 20 years, ok... 30 years tops Yes, hence the "might". The point is that I am suggesting some consideration of what's actually needed before new ciphers are implemented. Mere inclusion in a somewhat dated RFC is perhaps not compelling. Which ciphers are actually needed by PSK users? My hope is that at this point RC4 and 3DES are not. It is highly likely that CBC AES-CBC is needed, perhaps also Camellia, but the question is I think worth asking. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2464] TLS-RSA-PSK support
On Thursday 30 July 2015 15:09:18 Viktor Dukhovni wrote: > On Sun, Jun 21, 2015 at 07:00:55PM +, Giuseppe D'Angelo via RT wrote: > > diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod > > index c2d40ac..7fbe3a4 100644 > > --- a/doc/apps/ciphers.pod > > +++ b/doc/apps/ciphers.pod > > @@ -585,10 +585,22 @@ Note: these ciphers can also be used in SSL v3. > > > > =head2 Pre shared keying (PSK) ciphersuites > > > > + TLS_RSA_PSK_WITH_RC4_128_SHA RSA-PSK-RC4-SHA > > + TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA-PSK-3DES-EDE-CBC-SHA > > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA-PSK-AES128-CBC-SHA > > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA-PSK-AES256-CBC-SHA > > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 RSA-PSK-AES128-CBC-SHA256 > > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 RSA-PSK-AES256-CBC-SHA384 > > + TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 RSA-PSK-AES128-GCM-SHA256 > > + TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 RSA-PSK-AES256-GCM-SHA384 > > > > TLS_PSK_WITH_RC4_128_SHA PSK-RC4-SHA > > TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK-3DES-EDE-CBC-SHA > > TLS_PSK_WITH_AES_128_CBC_SHA PSK-AES128-CBC-SHA > > TLS_PSK_WITH_AES_256_CBC_SHA PSK-AES256-CBC-SHA > > > > + TLS_PSK_WITH_AES_128_CBC_SHA256 PSK-AES128-CBC-SHA256 > > + TLS_PSK_WITH_AES_256_CBC_SHA384 PSK-AES256-CBC-SHA384 > > + TLS_PSK_WITH_AES_128_GCM_SHA256 PSK-AES128-GCM-SHA256 > > + TLS_PSK_WITH_AES_256_GCM_SHA384 PSK-AES256-GCM-SHA384 > > Question, should we really be adding new RC4 or new 3DES ciphersuites? > Both ciphers are rather obsolete now. And we even have an RFC that > "bans" RC4. While I have been known to resist potentially premature > removal of *existing* RC4 support, I am certainly not a fan of RC4 > and see no reason to add more RC4 to OpenSSL. those are PSK ciphers, unless you set up PSK they won't be advertised at all, adding support for them has minimal impact on Internet use (be it port 443 or otherwise) of RC4 and 3DES and for people that actually need this support, it's better that they use OpenSSL than a home-cooked solution by an intern > I am not even sure that adding Camellia is a net win, ideally AES > and (soonish) ChaCha20 are enough. Camellia is the recommended backup cipher by ENISA, rightfully so > One might similarly question the longevity of the new CBC suites, > TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be > used for session resumption in 1.3). I give them 20 years, ok... 30 years tops > How many of the new ciphersuites are used/needed in practice? Which > are MTI for PSK? I think that when adding ciphersuites, we have > the opportunity/responsibility to exercise good judgement and enable > only the essential ones, and try to keep a lid on needless ciphersuite > proliferation. this horse left the barn, the barn got overgrown, people cut the trees and now are building a new barn -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3973] few options in s_client and s_server are missing descriptions
-curves, -sigalgs, -client_sigalgs are not documented in s_client and s_server -help messages fixes: https://github.com/openssl/openssl/pull/351 (1.0.2) https://github.com/openssl/openssl/pull/350 (master) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: PGP signature ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3967] Assert hit in the latest 1.0.2d code
Yes that worked. The previous version we were using 1.0.1m. Thanks for the quick turn around -Praveen On Wed, Jul 29, 2015 at 3:35 PM, Matt Caswell via RT wrote: > On Wed Jul 29 20:30:22 2015, prav...@viptela.com wrote: > > We seem to hit this assert with the latest code. Our sockets are all in > > non-blocking fashion. I dont see this assert in the previous releases. > > What was the last release you tried where this worked? Was this previously > working on a 1.0.2 release? > > > > > Can somebody throw more light on to this ? It is urgent. As we are not > able > > to migrate to this version because of this regression. > > Please can you try the attached patch and let me know if that makes any > difference. There seems to be an issue with DTLS1.2. If the underlying BIO > write buffers are full DTLS is supposed to drop the packet and clear out > the > internal OpenSSL buffer. This code was only testing for DTLS1 not DTLS1 and > DTLS1.2. If you are using DTLS1.2 then the internal buffer does not get > cleared > out, and the next time you try to write some data it falls over because the > buffer should be empty but it isn't. > > Matt > > -- -Praveen ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3972] EVP documentation implicitly recommends the use of single-DES
fixed in master and 1.0.2, thanks. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
Hi, On Fri, 31 Jul 2015 14:37:30 + "Salz, Rich" wrote: > Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some > more details. > > Summary: Moving to Apache 2, CLA's coming, it will take time. This is a huge step if it works (I leave it up to the lawyers to decide if it will), but I want to question whether Apache License is really a wise move. AFAIK there has been work done to make the apache license compatible with the GPL, both with changes in the APache license and the GPL, but this only applies to the GPL 3. Whether one likes that or not, there is still a lot of GPL2-only code out there and that's unlikely to change because for some projects it's close to impossible to change the license due to the number of contributors. Just to give a very concrete example: Apache 2 licensing would mean that the linux kernel could not take code from OpenSSL. In the spirit of making OpenSSL as useful as possible for everyone I would consider a permissive license that's more compatible (e.g. MIT) a wiser choice. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpRcb97ky2Ry.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Fri, Jul 31, 2015 at 02:36:03AM +, p...@securecottage.com wrote: > > Hi there, > > I have looked at the RSA protocol a bit and have concluded that > > 1) common factors in (p-1) and (q-1) are also in the factorisation of > (p*q-1). 2) by factoring (p*q-1) you can come up with candidates for > squares in the totient. 3) you can also come up with d mod > commonfactor^2 if there is a common factor. > > the math is shown in my wikipedia users page math blog at: > > https://en.wikipedia.org/wiki/User:Endo999#The_Bad_Stuff_That_Happens_When_There_Are_Common_Factors_Between_.28P-1.29_and_.28Q-1.29 [SNIP] Hi. How are you finding a common factor f such that f|(p-1) and f|(q-1)? Thanks. --mancha -- https://twitter.com/mancha140 pgpAx_elyqxEZ.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3742] Support s_client -starttls to xmpp server-to-server ports
merged into master, thanks! -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3963] [PATCH] Fix -rev, -www and -WWW modes to also allow OCSP-stapled responses
fixed, thanks! -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3962] [PATCH] Fix behavior of unspecified number of requests for OCSP responder
done, thanks! -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3961] [PATCH] Fix broken argument parsing for genrsa
PR merged, thanks. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3959] misleading comment in openssl-1.0.2
comment fixed in 1.0.2 and master, thanks. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] We're working on license changes
Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some more details. Summary: Moving to Apache 2, CLA's coming, it will take time. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3
Hi Matt, Thanks for the details. I can compile the same without any issues for Linux platform. But facing issues with Windows currently. Thanks, Kannan Narayanasamy. -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Friday, July 31, 2015 6:38 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 On 31/07/15 13:51, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Hi All, > > Any pointers on this much appreciated. I just tried it and those options appear to be broken for 0.9.8. I suspect they've been that way for a long time. That version is only receiving security fixes now so it won't be fixed either. Your only option is to use a more up to date version (which is advisable anyway since security fixes stop for 0.9.8 at the end of this year). Matt > > Thanks, > Kannan Narayanasamy. > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf > Of Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at > Cisco) > Sent: Monday, July 27, 2015 9:39 AM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 > no-ssl3 > > Hi Team, > > Can anyone share the thoughts on this? > > Thanks, > Kannan Narayanasamy. > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf > Of Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at > Cisco) > Sent: Thursday, July 23, 2015 5:46 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 > no-ssl3 > > Any thoughts much appreciated. > > ~Kannan N. > > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf > Of Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at > Cisco) > Sent: Wednesday, July 22, 2015 4:54 PM > To: openssl-dev@openssl.org > Subject: [openssl-dev] Compilation error while ignoring no-ssl2 > no-ssl3 > > Hi, > > To disable SSLv2 and SSLv3 while compilation used no-ssl2 and no-ssl3 option > for windows platform. But getting the below link error. Without option > "no-ssl2 no-ssl3" I can compile successfully. Any pointers to resolve this > issue? Thanks in advance. > > LINK : warning LNK4001: no object files specified; libraries used LINK > : warning LNK4068: /MACHINE not specified; defaulting to IX86 LINK : > warning LNK4001: no object files specified; libraries used > SSLEAY32.def : error LNK2001: unresolved external symbol BIO_f_ssl > SSLEAY32.def : error LNK2001: unresolved external symbol > BIO_new_buffer_ssl_connec SSLEAY32.def : error LNK2001: unresolved > external symbol BIO_new_ssl SSLEAY32.def : error LNK2001: unresolved > external symbol BIO_new_ssl_connect SSLEAY32.def : error LNK2001: > unresolved external symbol BIO_ssl_copy_session_id SSLEAY32.def : > error LNK2001: unresolved external symbol BIO_ssl_shutdown > SSLEAY32.def : error LNK2001: unresolved external symbol > DTLSv1_client_method SSLEAY32.def : error LNK2001: unresolved external > symbol DTLSv1_method SSLEAY32.def : error LNK2001: unresolved external > symbol DTLSv1_server_method SSLEAY32.def : error LNK2001: unresolved > external symbol ERR_load_SSL_strings SSLEAY32.def : error LNK2001: > unresolved e x >ternal symbol SSL_CIPHER_description SSLEAY32.def : error LNK2001: > unresolved external symbol SSL_CIPHER_get_bits SSLEAY32.def : error > LNK2001: unresolved external symbol SSL_CIPHER_get_name SSLEAY32.def : > error LNK2001: unresolved external symbol SSL_CIPHER_get_version > SSLEAY32.def : error LNK2001: unresolved external symbol > SSL_COMP_add_compression_ SSLEAY32.def : error LNK2001: unresolved > external symbol SSL_COMP_get_compression_ SSLEAY32.def : error > LNK2001: unresolved external symbol SSL_COMP_get_name SSLEAY32.def : > error LNK2001: unresolved external symbol SSL_CTX_add_client_CA > SSLEAY32.def : error LNK2001: unresolved external symbol > SSL_CTX_add_session SSLEAY32.def : error LNK2001: unresolved external > symbol SSL_CTX_callback_ctrl SSLEAY32.def : error LNK2001: unresolved > external symbol SSL_CTX_check_private_key > > Openssl Version: openssl-0.9.8zc > > Commands used: > > VCVARS32.BAT > perl Configure VC-WIN32 no-idea shared no-ssl2 no-ssl3 > --prefix=e:/openssl ms\do_masm nmake -f ms\ntdll.mak > > > > Thanks, > Kannan Narayanasamy. > > > > > > ___ > 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 > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___
Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3
On 31/07/15 13:51, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Hi All, > > Any pointers on this much appreciated. I just tried it and those options appear to be broken for 0.9.8. I suspect they've been that way for a long time. That version is only receiving security fixes now so it won't be fixed either. Your only option is to use a more up to date version (which is advisable anyway since security fixes stop for 0.9.8 at the end of this year). Matt > > Thanks, > Kannan Narayanasamy. > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of > Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) > Sent: Monday, July 27, 2015 9:39 AM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 > > Hi Team, > > Can anyone share the thoughts on this? > > Thanks, > Kannan Narayanasamy. > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of > Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) > Sent: Thursday, July 23, 2015 5:46 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 > > Any thoughts much appreciated. > > ~Kannan N. > > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of > Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) > Sent: Wednesday, July 22, 2015 4:54 PM > To: openssl-dev@openssl.org > Subject: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 > > Hi, > > To disable SSLv2 and SSLv3 while compilation used no-ssl2 and no-ssl3 option > for windows platform. But getting the below link error. Without option > "no-ssl2 no-ssl3" I can compile successfully. Any pointers to resolve this > issue? Thanks in advance. > > LINK : warning LNK4001: no object files specified; libraries used LINK : > warning LNK4068: /MACHINE not specified; defaulting to IX86 LINK : warning > LNK4001: no object files specified; libraries used SSLEAY32.def : error > LNK2001: unresolved external symbol BIO_f_ssl SSLEAY32.def : error LNK2001: > unresolved external symbol BIO_new_buffer_ssl_connec SSLEAY32.def : error > LNK2001: unresolved external symbol BIO_new_ssl SSLEAY32.def : error LNK2001: > unresolved external symbol BIO_new_ssl_connect SSLEAY32.def : error LNK2001: > unresolved external symbol BIO_ssl_copy_session_id SSLEAY32.def : error > LNK2001: unresolved external symbol BIO_ssl_shutdown SSLEAY32.def : error > LNK2001: unresolved external symbol DTLSv1_client_method SSLEAY32.def : error > LNK2001: unresolved external symbol DTLSv1_method SSLEAY32.def : error > LNK2001: unresolved external symbol DTLSv1_server_method SSLEAY32.def : error > LNK2001: unresolved external symbol ERR_load_SSL_strings SSLEAY32.def : error > LNK2001: unresolved e x >ternal symbol SSL_CIPHER_description SSLEAY32.def : error LNK2001: > unresolved external symbol SSL_CIPHER_get_bits SSLEAY32.def : error LNK2001: > unresolved external symbol SSL_CIPHER_get_name SSLEAY32.def : error LNK2001: > unresolved external symbol SSL_CIPHER_get_version SSLEAY32.def : error > LNK2001: unresolved external symbol SSL_COMP_add_compression_ SSLEAY32.def : > error LNK2001: unresolved external symbol SSL_COMP_get_compression_ > SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_get_name > SSLEAY32.def : error LNK2001: unresolved external symbol > SSL_CTX_add_client_CA SSLEAY32.def : error LNK2001: unresolved external > symbol SSL_CTX_add_session SSLEAY32.def : error LNK2001: unresolved external > symbol SSL_CTX_callback_ctrl SSLEAY32.def : error LNK2001: unresolved > external symbol SSL_CTX_check_private_key > > Openssl Version: openssl-0.9.8zc > > Commands used: > > VCVARS32.BAT > perl Configure VC-WIN32 no-idea shared no-ssl2 no-ssl3 --prefix=e:/openssl > ms\do_masm nmake -f ms\ntdll.mak > > > > Thanks, > Kannan Narayanasamy. > > > > > > ___ > 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 > ___ > 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 > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3
Hi All, Any pointers on this much appreciated. Thanks, Kannan Narayanasamy. -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) Sent: Monday, July 27, 2015 9:39 AM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 Hi Team, Can anyone share the thoughts on this? Thanks, Kannan Narayanasamy. -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) Sent: Thursday, July 23, 2015 5:46 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 Any thoughts much appreciated. ~Kannan N. -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) Sent: Wednesday, July 22, 2015 4:54 PM To: openssl-dev@openssl.org Subject: [openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3 Hi, To disable SSLv2 and SSLv3 while compilation used no-ssl2 and no-ssl3 option for windows platform. But getting the below link error. Without option "no-ssl2 no-ssl3" I can compile successfully. Any pointers to resolve this issue? Thanks in advance. LINK : warning LNK4001: no object files specified; libraries used LINK : warning LNK4068: /MACHINE not specified; defaulting to IX86 LINK : warning LNK4001: no object files specified; libraries used SSLEAY32.def : error LNK2001: unresolved external symbol BIO_f_ssl SSLEAY32.def : error LNK2001: unresolved external symbol BIO_new_buffer_ssl_connec SSLEAY32.def : error LNK2001: unresolved external symbol BIO_new_ssl SSLEAY32.def : error LNK2001: unresolved external symbol BIO_new_ssl_connect SSLEAY32.def : error LNK2001: unresolved external symbol BIO_ssl_copy_session_id SSLEAY32.def : error LNK2001: unresolved external symbol BIO_ssl_shutdown SSLEAY32.def : error LNK2001: unresolved external symbol DTLSv1_client_method SSLEAY32.def : error LNK2001: unresolved external symbol DTLSv1_method SSLEAY32.def : error LNK2001: unresolved external symbol DTLSv1_server_method SSLEAY32.def : error LNK2001: unresolved external symbol ERR_load_SSL_strings SSLEAY32.def : error LNK2001: unresolved ex ternal symbol SSL_CIPHER_description SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_get_bits SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_get_name SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_get_version SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_add_compression_ SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_get_compression_ SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_get_name SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_add_client_CA SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_add_session SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_callback_ctrl SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_check_private_key Openssl Version: openssl-0.9.8zc Commands used: VCVARS32.BAT perl Configure VC-WIN32 no-idea shared no-ssl2 no-ssl3 --prefix=e:/openssl ms\do_masm nmake -f ms\ntdll.mak Thanks, Kannan Narayanasamy. ___ 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 ___ 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 #3968] HOSENT: redefinition error
Hi Julius, I am afraid this is not related to the 'dev' list. Did you try to modify the order of your header files as mentioned on several other forums ? http://comments.gmane.org/gmane.comp.encryption.openssl.devel/14135 (and include WinSock2.h before windows.h) Regards, Michel -Message d'origine- De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Julius Villapando via RT Envoyé : jeudi 30 juillet 2015 13:25 Cc : openssl-dev@openssl.org Objet : [openssl-dev] [openssl.org #3968] HOSENT: redefinition error Hi, I'm trying to use the openssl library along with other libraries but the HOSENT in bio.h conflicts with winsock.h HOSENT, do you guys have a solution for this, or can I request that you change the name of HOSENT to avoid the redefinition error? Thanks in advance. Here is the error:openssl/bio.h(729) : error C2371: 'HOSTENT' : redefinition; different basic types winsock.h(1029) : see declaration of 'HOSTENT' ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3968] HOSENT: redefinition error
Hi Julius, I am afraid this is not related to the 'dev' list. Did you try to modify the order of your header files as mentioned on several other forums ? http://comments.gmane.org/gmane.comp.encryption.openssl.devel/14135 (and include WinSock2.h before windows.h) Regards, Michel -Message d'origine- De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Julius Villapando via RT Envoyé : jeudi 30 juillet 2015 13:25 Cc : openssl-dev@openssl.org Objet : [openssl-dev] [openssl.org #3968] HOSENT: redefinition error Hi, I'm trying to use the openssl library along with other libraries but the HOSENT in bio.h conflicts with winsock.h HOSENT, do you guys have a solution for this, or can I request that you change the name of HOSENT to avoid the redefinition error? Thanks in advance. Here is the error:openssl/bio.h(729) : error C2371: 'HOSTENT' : redefinition; different basic types winsock.h(1029) : see declaration of 'HOSTENT' ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Fri, 2015-07-31 at 03:09 +, Salz, Rich wrote:
> > If requested, I can still provide a patch with the alternative variant of
> > using a
> > X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
> > 'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
>
> Yes, please.
[dwoodhou@i7 apps]$ ./openssl verify ~/.cert.20100813/certificate.pem
C = US, O = Intel Corporation, CN = Intel Intranet Basic Issuing CA 1B
error 10 at 1 depth lookup:certificate has expired
DC = com, DC = intel, DC = corp, DC = ger, OU = Workers, CN = "Woodhouse,
David", emailAddress = david.woodho...@intel.com
error 10 at 0 depth lookup:certificate has expired
/home/dwmw2/.cert.20100813/certificate.pem: OK
[dwoodhou@i7 apps]$ ./openssl verify -no_check_time
~/.cert.20100813/certificate.pem
/home/dwmw2/.cert.20100813/certificate.pem: OK
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
>From 782cf323f9a85c9244dc6aceb13d875723253810 Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Fri, 31 Jul 2015 08:49:50 +0100
Subject: [PATCH] RT3951: Add X509_V_FLAG_NO_CHECK_TIME to suppress time check
In some environments, such as firmware, the current system time is entirely
meaningless. Provide a clean mechanism to suppress the checks against it.
---
apps/apps.h| 8 +---
apps/opt.c | 4
crypto/x509/x509_vfy.c | 4
doc/crypto/X509_VERIFY_PARAM_set_flags.pod | 4
include/openssl/x509_vfy.h | 2 ++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/apps/apps.h b/apps/apps.h
index f2dc812..1781deb 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -179,7 +179,7 @@ void unbuffer(FILE *fp);
OPT_V_X509_STRICT, OPT_V_EXTENDED_CRL, OPT_V_USE_DELTAS, \
OPT_V_POLICY_PRINT, OPT_V_CHECK_SS_SIG, OPT_V_TRUSTED_FIRST, \
OPT_V_SUITEB_128_ONLY, OPT_V_SUITEB_128, OPT_V_SUITEB_192, \
-OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, \
+OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, OPT_V_NO_CHECK_TIME, \
OPT_V__LAST
# define OPT_V_OPTIONS \
@@ -209,7 +209,8 @@ void unbuffer(FILE *fp);
{ "suiteB_128", OPT_V_SUITEB_128, '-' }, \
{ "suiteB_192", OPT_V_SUITEB_192, '-' }, \
{ "partial_chain", OPT_V_PARTIAL_CHAIN, '-' }, \
-{ "no_alt_chains", OPT_V_NO_ALT_CHAINS, '-', "Only use the first cert chain found" }
+{ "no_alt_chains", OPT_V_NO_ALT_CHAINS, '-', "Only use the first cert chain found" }, \
+{ "no_check_time", OPT_V_NO_CHECK_TIME, '-', "Do not check validity against current time" }
# define OPT_V_CASES \
OPT_V__FIRST: case OPT_V__LAST: break; \
@@ -239,7 +240,8 @@ void unbuffer(FILE *fp);
case OPT_V_SUITEB_128: \
case OPT_V_SUITEB_192: \
case OPT_V_PARTIAL_CHAIN: \
-case OPT_V_NO_ALT_CHAINS
+case OPT_V_NO_ALT_CHAINS: \
+case OPT_V_NO_CHECK_TIME
/*
* Common "extended"? options.
diff --git a/apps/opt.c b/apps/opt.c
index bfb039e..c7dcc43 100644
--- a/apps/opt.c
+++ b/apps/opt.c
@@ -543,6 +543,10 @@ int opt_verify(int opt, X509_VERIFY_PARAM *vpm)
break;
case OPT_V_NO_ALT_CHAINS:
X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_ALT_CHAINS);
+ break;
+case OPT_V_NO_CHECK_TIME:
+X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_CHECK_TIME);
+ break;
}
return 1;
diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 7062ab2..a1bf0f2 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -952,6 +952,8 @@ static int check_crl_time(X509_STORE_CTX *ctx, X509_CRL *crl, int notify)
ctx->current_crl = crl;
if (ctx->param->flags & X509_V_FLAG_USE_CHECK_TIME)
ptime = &ctx->param->check_time;
+else if (ctx->param->flags & X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
@@ -1672,6 +1674,8 @@ int x509_check_cert_time(X509_STORE_CTX *ctx, X509 *x, int quiet)
if (ctx->param->flags & X509_V_FLAG_USE_CHECK_TIME)
ptime = &ctx->param->check_time;
+else if (ctx->param->flags & X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
diff --git a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
index 066ce0f..57c7b7b 100644
--- a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
+++ b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
@@ -203,6 +203,10 @@ chain found is not trusted, then OpenSSL will continue to check to see if an
alternative chain can be found that is trusted. With this flag set the behaviour
will match that of OpenSSL versions prior to 1.1.0.
+The B flag suppresses checking the validity period
+of certificates and CRLs against the current time. If X509_VERIFY_PARAM_set_time()
+is used to specify a verification time, the check is not suppressed.
+
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Fri, 2015-07-31 at 03:09 +, Salz, Rich wrote:
> > If requested, I can still provide a patch with the alternative variant of
> > using a
> > X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
> > 'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
>
> Yes, please.
[dwoodhou@i7 apps]$ ./openssl verify ~/.cert.20100813/certificate.pem
C = US, O = Intel Corporation, CN = Intel Intranet Basic Issuing CA 1B
error 10 at 1 depth lookup:certificate has expired
DC = com, DC = intel, DC = corp, DC = ger, OU = Workers, CN = "Woodhouse,
David", emailAddress = david.woodho...@intel.com
error 10 at 0 depth lookup:certificate has expired
/home/dwmw2/.cert.20100813/certificate.pem: OK
[dwoodhou@i7 apps]$ ./openssl verify -no_check_time
~/.cert.20100813/certificate.pem
/home/dwmw2/.cert.20100813/certificate.pem: OK
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 782cf323f9a85c9244dc6aceb13d875723253810 Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Fri, 31 Jul 2015 08:49:50 +0100
Subject: [PATCH] RT3951: Add X509_V_FLAG_NO_CHECK_TIME to suppress time check
In some environments, such as firmware, the current system time is entirely
meaningless. Provide a clean mechanism to suppress the checks against it.
---
apps/apps.h| 8 +---
apps/opt.c | 4
crypto/x509/x509_vfy.c | 4
doc/crypto/X509_VERIFY_PARAM_set_flags.pod | 4
include/openssl/x509_vfy.h | 2 ++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/apps/apps.h b/apps/apps.h
index f2dc812..1781deb 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -179,7 +179,7 @@ void unbuffer(FILE *fp);
OPT_V_X509_STRICT, OPT_V_EXTENDED_CRL, OPT_V_USE_DELTAS, \
OPT_V_POLICY_PRINT, OPT_V_CHECK_SS_SIG, OPT_V_TRUSTED_FIRST, \
OPT_V_SUITEB_128_ONLY, OPT_V_SUITEB_128, OPT_V_SUITEB_192, \
-OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, \
+OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, OPT_V_NO_CHECK_TIME, \
OPT_V__LAST
# define OPT_V_OPTIONS \
@@ -209,7 +209,8 @@ void unbuffer(FILE *fp);
{ "suiteB_128", OPT_V_SUITEB_128, '-' }, \
{ "suiteB_192", OPT_V_SUITEB_192, '-' }, \
{ "partial_chain", OPT_V_PARTIAL_CHAIN, '-' }, \
-{ "no_alt_chains", OPT_V_NO_ALT_CHAINS, '-', "Only use the first cert chain found" }
+{ "no_alt_chains", OPT_V_NO_ALT_CHAINS, '-', "Only use the first cert chain found" }, \
+{ "no_check_time", OPT_V_NO_CHECK_TIME, '-', "Do not check validity against current time" }
# define OPT_V_CASES \
OPT_V__FIRST: case OPT_V__LAST: break; \
@@ -239,7 +240,8 @@ void unbuffer(FILE *fp);
case OPT_V_SUITEB_128: \
case OPT_V_SUITEB_192: \
case OPT_V_PARTIAL_CHAIN: \
-case OPT_V_NO_ALT_CHAINS
+case OPT_V_NO_ALT_CHAINS: \
+case OPT_V_NO_CHECK_TIME
/*
* Common "extended"? options.
diff --git a/apps/opt.c b/apps/opt.c
index bfb039e..c7dcc43 100644
--- a/apps/opt.c
+++ b/apps/opt.c
@@ -543,6 +543,10 @@ int opt_verify(int opt, X509_VERIFY_PARAM *vpm)
break;
case OPT_V_NO_ALT_CHAINS:
X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_ALT_CHAINS);
+ break;
+case OPT_V_NO_CHECK_TIME:
+X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_CHECK_TIME);
+ break;
}
return 1;
diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 7062ab2..a1bf0f2 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -952,6 +952,8 @@ static int check_crl_time(X509_STORE_CTX *ctx, X509_CRL *crl, int notify)
ctx->current_crl = crl;
if (ctx->param->flags & X509_V_FLAG_USE_CHECK_TIME)
ptime = &ctx->param->check_time;
+else if (ctx->param->flags & X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
@@ -1672,6 +1674,8 @@ int x509_check_cert_time(X509_STORE_CTX *ctx, X509 *x, int quiet)
if (ctx->param->flags & X509_V_FLAG_USE_CHECK_TIME)
ptime = &ctx->param->check_time;
+else if (ctx->param->flags & X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
diff --git a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
index 066ce0f..57c7b7b 100644
--- a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
+++ b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
@@ -203,6 +203,10 @@ chain found is not trusted, then OpenSSL will continue to check to see if an
alternative chain can be found that is trusted. With this flag set the behaviour
will match that of OpenSSL versions prior to 1.1.0.
+The B flag suppresses checking the validity period
+of certificates and CRLs against the current time. If X509_VERIFY_PARAM_set_time()
+is used to specify a verification time, the check is not suppressed.
+
=
