What is the underlying algorithm in RAND_bytes() function?

2014-05-12 Thread harika_n
I am using RAND_bytes function to generate cryptographically secure random
numbers. I want to know if it uses Hash based DRBG or HMAC based DRBG. If it
uses Hash based DRBG what is the underlying hash function used? I looked at
the source code and found that it uses some MD function but I could not find
which MD it is using.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/What-is-the-underlying-algorithm-in-RAND-bytes-function-tp50089.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


[1.0.2 beta 1] double free when using CMS with OAEP

2014-05-12 Thread Kevin Le Gouguec
(This is on 1.0.2 beta 1 as found on openssl.org/source)

I'm getting a double free error when building a CMS EnvelopedData with RSA 
OAEP. Here's how I'm setting things up (error checking left out for brevity):

  int flags = CMS_BINARY | CMS_USE_KEYID | CMS_PARTIAL | CMS_KEY_PARAM;

  CMS_ContentInfo* edata = CMS_encrypt(NULL, NULL, cipher, flags);

  CMS_RecipientInfo* r_info = CMS_add1_recipient_cert(edata, r_cert, flags);

  EVP_PKEY_CTX* wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info);
  EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING);
  EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256());
  EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256());
  EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, my_label, my_label_l);

  CMS_final(edata, in, NULL, flags);


Valgrind says:

==13434== Invalid free() / delete / delete[]
==13434==at 0x4024B3A: free (vg_replace_malloc.c:366)
==13434==by 0x8087BE4: CRYPTO_free (mem.c:397)
==13434==by 0x80B27AC: pkey_rsa_cleanup (rsa_pmeth.c:175)
==13434==by 0x80615E7: EVP_PKEY_CTX_free (pmeth_lib.c:374)
==13434==by 0x8082DED: cms_RecipientInfo_ktri_encrypt (cms_env.c:433)
==13434==by 0x8083930: CMS_RecipientInfo_encrypt (cms_env.c:896)
==13434==by 0x8083BC5: cms_EnvelopedData_init_bio (cms_env.c:1013)
==13434==by 0x807D885: CMS_dataInit (cms_lib.c:141)
==13434==by 0x8080358: CMS_final (cms_smime.c:807)
==13434==by 0x804A5C4: snip
==13434==  Address 0xbeb16466 is on thread 1's stack


Might be a case of PEBKAC, I mostly guessed how this was supposed to work based 
on [1], so I might be doing retarded things.

[1] 
https://github.com/openssl/openssl/commit/f2edf3181e30413c99864e7106125be7da905678




Some more code if anyone wants to try:

#define OSSL_FAIL { ERR_print_errors_fp(stderr); goto end; }

  OpenSSL_add_all_algorithms();
  ERR_load_crypto_strings();

  BIO* in = NULL;
  BIO* tmp_out = NULL;
  CMS_ContentInfo* edata = NULL;
  const EVP_CIPHER* cipher = EVP_aes_256_cbc();

  /* Retrieve recipient certificate */
  FILE* r_cert_file = fopen(recip_cert_path, rb);
  if (!r_cert_file) {
printf(Could not open certificate at %s.\n, recip_cert_path);
goto end;
  }
  if (!PEM_read_X509(r_cert_file, r_cert, NULL, NULL)) OSSL_FAIL;
  fclose(r_cert_file);

  in = BIO_new_file(in_path, rb);
  if (!in) OSSL_FAIL;

  int flags = CMS_BINARY | CMS_USE_KEYID | CMS_PARTIAL | CMS_KEY_PARAM;

  edata = CMS_encrypt(NULL, NULL, cipher, flags);
  if (!edata) OSSL_FAIL;

  CMS_RecipientInfo* r_info = CMS_add1_recipient_cert(edata, r_cert, flags);
  if (!r_info) OSSL_FAIL;

  unsigned char oaep_label[] = BLORG;
  size_t oaep_label_l = sizeof(oaep_label);
  EVP_PKEY_CTX* wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info);
  if (!wrap_ctx) {
printf(oh noes! no wrap ctx :(\n);
goto end;
  }
  if (EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING)1)
OSSL_FAIL;
  if (EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256())1)
OSSL_FAIL;
  if (EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256())1)
OSSL_FAIL;
  if (EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, oaep_label, oaep_label_l)1)
OSSL_FAIL;

  if (! CMS_final(edata, in, NULL, flags) ) OSSL_FAIL;

  /* Out */
  char* env_out = malloc(strlen(in_path) + sizeof(.ENV.CMS));
  strncpy(env_out, in_path, strlen(out_path)+1);
  strcat(env_out, .ENV.CMS);
  BIO* tmp_out = BIO_new_file(env_out, wb);
  if (!tmp_out) OSSL_FAIL;
  if (!i2d_CMS_bio(tmp_out, edata)) OSSL_FAIL;
  if (BIO_flush(tmp_out)1) OSSL_FAIL;
  free(env_out);

end:
  if (edata) CMS_ContentInfo_free(edata);
  if (r_cert) X509_free(r_cert);
  if (in) BIO_free(in);
  if (tmp_out) BIO_free(tmp_out);

  ERR_free_strings();
  EVP_cleanup();


PS: Many thanks to Tom and Steve for their previous help on nested CMS 
structures :) ended up parsing the ASN.1 string myself, which was 1) not 
difficult 2) very instructive.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


[patch] Supporting smartcard readers with PIN entry keypads (updated against -HEAD)

2014-05-12 Thread Dirk-Willem van Gulik
Repost; updated for HEAD and tested on ubuntu as well.

Dw.

Folks,

Find below a minor patch to allow the use of smartcards in readers that have 
their own
PIN entry keypads (Secure PIN entry) such as the SPR332 and most german/medical
chipcard devices.

Tested on Solaris, FreeBSD, Linux and MacOSX against various cards and drivers.

I’ve left the pkcs11_interactive check in place. Arguably - with some Secure 
PIN readers
it may be better to move this just in front of the keyboard entry ONLY; as 
there are some
secure PIN keypads that use means which are somewhat suitable to unattended 
operation. But I thought it better to let this wait until an actual use case 
warrants this
and/or the need for a special flag/argument to control such.

Thanks,

Dw.

Index: ssh-pkcs11.c
===
RCS file: /cvs/openssh/ssh-pkcs11.c,v
retrieving revision 1.15
diff -u -w -r1.15 ssh-pkcs11.c
--- ssh-pkcs11.c20 Apr 2014 03:21:23 -  1.15
+++ ssh-pkcs11.c12 May 2014 12:34:25 -
@@ -255,21 +255,29 @@
si = k11-provider-slotinfo[k11-slotidx];
if ((si-token.flags  CKF_LOGIN_REQUIRED)  !si-logged_in) {
if (!pkcs11_interactive) {
-   error(need pin);
+   error(need pin entry%s, 
+   (si-token.flags  
CKF_PROTECTED_AUTHENTICATION_PATH) ?  on reader keypad : );
return (-1);
}
+   if (si-token.flags  CKF_PROTECTED_AUTHENTICATION_PATH) {
+   verbose(Deferring PIN entry to keypad of chipcard 
reader.);
+   pin = NULL;
+   } else {
snprintf(prompt, sizeof(prompt), Enter PIN for '%s': ,
si-token.label);
pin = read_passphrase(prompt, RP_ALLOW_EOF);
if (pin == NULL)
return (-1);/* bail out */
-   if ((rv = f-C_Login(si-session, CKU_USER,
-   (u_char *)pin, strlen(pin))) != CKR_OK) {
-   free(pin);
+   };
+   if ((rv = f-C_Login(si-session, CKU_USER, pin, pin ? 
strlen(pin): 0))
+   != CKR_OK) {
+   if (pin)
+   xfree(pin);
error(C_Login failed: %lu, rv);
return (-1);
}
-   free(pin);
+   if (pin) 
+   xfree(pin);
si-logged_in = 1;
}
key_filter[1].pValue = k11-keyid;

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: What is the underlying algorithm in RAND_bytes() function?

2014-05-12 Thread Marcus Meissner
On Mon, May 12, 2014 at 03:00:23AM -0700, harika_n wrote:
 I am using RAND_bytes function to generate cryptographically secure random
 numbers. I want to know if it uses Hash based DRBG or HMAC based DRBG. If it
 uses Hash based DRBG what is the underlying hash function used? I looked at
 the source code and found that it uses some MD function but I could not find
 which MD it is using.

Depending on what random generator engine is used. The default builtin one
is a hash based DRBG.

crypto/rand/rand_lcl.h ... the default MD is SHA1.

Ciao, Marcus
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: CRL default_crl_days

2014-05-12 Thread Eisenacher, Patrick
Hi Gregory,

 -Original Message-
 From: Gregory Sloop

[snip]

 So, I thought - why should I set the default_crl_days to some low
 number. I assume that it [the CRL] can be replaced with a new CRL,
 should we need one, long before the default_crl_days limit is reached.
 Is that correct?

Yes, this is correct.

 So, if that's the case, what would be the downside of making the
 default_crl_days equal to the validity of the CA itself, for example?
 [e.g. If the CA cert is valid for 100 years, why not set the
 default_crl_days to 36500+/- days too?]

Every certificate that is revoked after the crl's issuance is naturally not 
contained in it. So a client querying a crl for a certificate's revocation 
status will falsely accept every certificate that was revoked after the crl's 
issuance. The longer your crl is valid, the more revoked certificates will slip 
through the check. Plus, the client has no need to update the crl as long as it 
is valid. This problem is inherent to crls. As such, you want to make your crls 
as short running as possible and usable in your environment.

HTH,
Patrick Eisenacher


Re: [1.0.2 beta 1] double free when using CMS with OAEP

2014-05-12 Thread Dr. Stephen Henson
On Mon, May 12, 2014, Kevin Le Gouguec wrote:

 (This is on 1.0.2 beta 1 as found on openssl.org/source)
 
 I'm getting a double free error when building a CMS EnvelopedData with RSA 
 OAEP. Here's how I'm setting things up (error checking left out for brevity):
 
 
   unsigned char oaep_label[] = BLORG;
   size_t oaep_label_l = sizeof(oaep_label);
   EVP_PKEY_CTX* wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info);
   if (!wrap_ctx) {
 printf(oh noes! no wrap ctx :(\n);
 goto end;
   }
   if (EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING)1)
 OSSL_FAIL;
   if (EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256())1)
 OSSL_FAIL;
   if (EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256())1)
 OSSL_FAIL;
   if (EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, oaep_label, oaep_label_l)1)
 OSSL_FAIL;
 

You problem is the OAEP label. The set0 in the function name means the
pointer is used and freed internally by OpenSSL and shouldn't be freed
outside. In this case the label hasn't been allocated using OPENSSL_malloc so
you'll get a problem when OpenSSL tries to free it.

If you allocate a buffer for the OAEP label using OPENSSL_malloc and pass that
you should have no problem.

See:

http://www.openssl.org/docs/crypto/crypto.html#NOTES

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: CRL default_crl_days

2014-05-12 Thread Jeffrey Walton
 So, if that's the case, what would be the downside of making the
 default_crl_days equal to the validity of the CA itself, for example?
 [e.g. If the CA cert is valid for 100 years, why not set the
 default_crl_days to 36500+/- days too?]

Because some clients won't check back for 100 years... Plus, these
things are cached, so the client may check more frequently but the
caching software may check every 100 years.

Gutmman does a good job with CRLs and OCSP in his book Engineering
Security (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). See
Chapter 8, PKI. From page 638:

When a CA issues a CRL, it bundles up a blacklist of
revoked certificates along with an issue date and a
second date indicating when the next blacklist will
become available. A relying party that doesn’t have
a current CRL is expected to fetch the current one and
use that to check the validity of the certificate...

Jeff

On Tue, May 6, 2014 at 7:36 PM, Gregory Sloop gr...@sloop.net wrote:
 So, I'm working with an EAP-TLS system running under freeradius.

 I've setup things to use a CRL [not OSCP] to revoke certificates and
 all works well.

 However, the parameter default_crl_days=XXX puzzles me.

 Through trial and error [mostly error] I know that if I don't
 regenerate the CTL every default_crl_days, the CRL expires and then
 freeradius won't auth anything at all.

 So, I thought - why should I set the default_crl_days to some low
 number. I assume that it [the CRL] can be replaced with a new CRL,
 should we need one, long before the default_crl_days limit is reached.
 Is that correct?

 So, if that's the case, what would be the downside of making the
 default_crl_days equal to the validity of the CA itself, for example?
 [e.g. If the CA cert is valid for 100 years, why not set the
 default_crl_days to 36500+/- days too?]

 I assume there's some other use, other than EAP-TLS, where doing this
 might be a bad plan, but I'm afraid I can't think of one in the
 EAP-TLS context with FreeRadius. Am I missing something?

 [And I'd be glad to be pointed to another context, if there is one,
 where setting a very long-ish default_crl_days would be bad - even if
 it's fine in the setting I'm discussing. Knowing would be good
 education.]

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: [1.0.2 beta 1] double free when using CMS with OAEP

2014-05-12 Thread Kevin Le Gouguec
Thanks! I guess if I had debugged more I would have seen that the invalid-freed 
pointer (and not *double*-freed like I assumed) corresponded to the label. I 
kept wondering what that address is on thread 1's stack referred to... Quite 
obvious in hindsight.

I just tried to allocate the label with OPENSSL_malloc and everything worked 
smoothly (also works with regular malloc). Thanks again! And sorry for the 
half-assed debugging.



- Original Message -
From: Dr. Stephen Henson st...@openssl.org
To: openssl-users@openssl.org
Sent: Monday, May 12, 2014 3:22:44 PM
Subject: Re: [1.0.2 beta 1] double free when using CMS with OAEP

On Mon, May 12, 2014, Kevin Le Gouguec wrote:

 (This is on 1.0.2 beta 1 as found on openssl.org/source)
 
 I'm getting a double free error when building a CMS EnvelopedData with RSA 
 OAEP. Here's how I'm setting things up (error checking left out for brevity):
 
 
   unsigned char oaep_label[] = BLORG;
   size_t oaep_label_l = sizeof(oaep_label);
   EVP_PKEY_CTX* wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info);
   if (!wrap_ctx) {
 printf(oh noes! no wrap ctx :(\n);
 goto end;
   }
   if (EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING)1)
 OSSL_FAIL;
   if (EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256())1)
 OSSL_FAIL;
   if (EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256())1)
 OSSL_FAIL;
   if (EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, oaep_label, oaep_label_l)1)
 OSSL_FAIL;
 

You problem is the OAEP label. The set0 in the function name means the
pointer is used and freed internally by OpenSSL and shouldn't be freed
outside. In this case the label hasn't been allocated using OPENSSL_malloc so
you'll get a problem when OpenSSL tries to free it.

If you allocate a buffer for the OAEP label using OPENSSL_malloc and pass that
you should have no problem.

See:

http://www.openssl.org/docs/crypto/crypto.html#NOTES

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


How to check if certificate is a EV-SSL certificate?

2014-05-12 Thread Steve Behrendt
Hi everyone,


I'm building an iOS application and trying to check if a certificate, that a 
https-connection uses, is a EV certificate.


Does the OpenSSL-libary have a method that gives me that information, if a 
given certificate is a EV certificate?



I found the method

X509_get_ext_d2i(certificateX509, NID_certificate_policies, NULL, NULL)

?which returns some data depending of the NID provided. Since it is a 
void-pointer, I don't know, which data type it returns.


Thanks heaps!

Steve


Steve Behrendt

steve.behre...@netlight.commailto:steve.behre...@netlight.com

Netlight Consulting GmbH www.netlight.dehttp://www.netlight.de/
Residenzstr. 7, 80333 München
Mobile +49 160 4729799

Amtsgericht München, HRB 189944
Umsatzsteuer-Identifikation: DE276206820
Geschäftsführer: Felix Sprick

Please consider the environment before printing this email.

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.


RE: How to check if certificate is a EV-SSL certificate?

2014-05-12 Thread Salz, Rich
Ø  X509_get_ext_d2i(certificateX509, NID_certificate_policies, NULL, NULL)

Ø  ​which returns some data depending of the NID provided. Since it is a 
void-pointer, I don't know, which data type it returns.

According to x509v3/pcy_cache.c, it returns a pointer to CERTIFICATEPOLICIES.  
According to x509v3.h that’s a stack of POLICYINFO, which is also defined in 
that header, and most notably includes an ASN1_OBJECT which is the policyid.  
According to http://en.wikipedia.org/wiki/Extended_Validation_Certificate every 
CA uses its own policy id and there’s a table there.

You might also look at the Chrome and/or Firefox sources to see what they use.

Hope this helps.

/r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz


Re: How to check if certificate is a EV-SSL certificate?

2014-05-12 Thread Robert W Weaver
 I'm building an iOS application and trying to check if a certificate,
that a https-connection uses, is a EV certificate.

Why?

Wikipedia notes The primary way to identify an EV certificate is by
referencing the Certificate Policies extension field. Each issuer uses a
different object identifier (OID) in this field to identify their EV
certificates, and each OID is documented in the issuer's Certification
Practice Statement. As with root certificate authorities in general,
browsers may not recognize all issuers.   It would seem to be a table
lookup issue.
--

 Dr. Robert Woody GBS Cybersecurity  
 Weaver Privacy 

 IT Security Architect  Cell: 301-524-8138  


--
It has been said that man is a rational animal. All my life I have
been searching for evidence which could support this.
-- Bertrand Russell


   
 Steve Behrendt
 steve.behrendt@n 
 etlight.com   To 
 Sent by:  openssl-users@openssl.org 
 owner-openssl-use openssl-users@openssl.org 
 r...@openssl.org cc 
   
   Subject 
 05/12/2014 10:59  How to check if certificate is a
 AMEV-SSL certificate? 
   
   
 Please respond to 
 openssl-users@ope 
 nssl.org  
   
   




Hi everyone,

I'm building an iOS application and trying to check if a certificate, that
a https-connection uses, is a EV certificate.

Does the OpenSSL-libary have a method that gives me that information, if a
given certificate is a EV certificate?


I found the method
X509_get_ext_d2i(certificateX509, NID_certificate_policies, NULL, NULL)
​which returns some data depending of the NID provided. Since it is a
void-pointer, I don't know, which data type it returns.

Thanks heaps!
Steve

Steve Behrendt

steve.behre...@netlight.com
Netlight Consulting GmbH www.netlight.de
Residenzstr. 7, 80333 München
Mobile +49 160 4729799
Amtsgericht München, HRB 189944
Umsatzsteuer-Identifikation: DE276206820
Geschäftsführer: Felix Sprick
Please consider the environment before printing this email.
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

RE: SSL_read() and dropped (half-open) connections

2014-05-12 Thread Michael Wojcik
 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
 us...@openssl.org] On Behalf Of Tilman Sauerbeck
 Sent: Friday, 09 May, 2014 18:57
 
 Michael Wojcik [2014-05-09 21:12]:
 
   From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
   us...@openssl.org] On Behalf Of Tilman Sauerbeck
   Sent: Thursday, 08 May, 2014 12:26
  
   my program is an SSL client which is reading large amounts of data
   without sending data itself (after the initial handshake).
   ...
   Another attempt was to use select() to check if the socket is readable
   just before calling SSL_read(), like so:
 
  That's not useful in your case. When you're receiving on a TCP connection
 and not sending, and the connection is closed, the socket will be flagged as
 readable. With select() you can't distinguish between a connection that has
 data available and a connection that has received a TCP FIN or RST.
 
 Yes, and I wanted to only ask OpenSSL to read from the socket if it was
 readable. I wouldn't care if that read() returned 0.

OK. I misinterpreted your original note.

I still don't know what exactly a dropped connection constitutes in your 
case, though, or how the TCP/IP stack is handling it. That makes quite a 
difference. If the stack treats it as transient, the socket won't be readable.

  I suspect it doesn't work because select is returning non-zero, because the
 socket is readable.
 
 If the socket was readable, the following call to SSL_read() wouldn't
 block though. However with that snippet, I'm still seeing hanging
 read() calls.

I'd have to debug through the SSL_read code to comment. I've seen it do some 
questionable things (in OpenSSL 0.9.8, which was the most recent version where 
I had cause to debug SSL_read), but the logic is convoluted enough that I 
didn't take the time to confirm the behavior was actually wrong.

  Only that usual practice for an application that wants to be able to abort
 a TCP receive operation is to use non-blocking sockets. SO_RCVTIMEO was
 created when threading became commonly available on UNIX platforms and
 blocking network I/O became a more usable approach for complex applications.
 Consequently, most people who want more control over the behavior of a
 passive TCP endpoint still use nonblocking sockets.
 
 I guess I thought SO_RCVTIMEO was widespread enough for OpenSSL to
 handle it or mention it in the documentation...

SO_RCVTIMEO is standard, as I noted, but SUSv3 doesn't require that it actually 
work. I don't know how widely it's implemented in contemporary TCP/IP stacks, 
or whether you have to support any old stacks that don't support it. What I 
meant above was more along the lines of because most people acquired the habit 
of using non-blocking sockets, probably there aren't many who have tried to use 
SO_RCVTIMEO with OpenSSL.

I don't think there's anything wrong with SO_RCVTIMEO (except for processes 
handling a lot of conversations, where non-blocking sockets and multiplexed I/O 
offer less overhead and more capacity than a bunch of threads blocking in 
network I/O). It simply may be something that the BIO code doesn't handle very 
well.

As for the OpenSSL documentation ... let's just say there are a lot of things 
it doesn't mention.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: How to check if certificate is a EV-SSL certificate?

2014-05-12 Thread Kyle Hamilton
There is no single OID for Extended Validation.  The members of CA/Browser
Forum (CABF) define their own, and then petition the browsers for EV
acceptance.  The browsers then add the root certificate to their internal
EV tables, along with the OID they use for EV.

Since OpenSSL does not include root certificates (and does not operate its
own root program), it has no means of knowing whether any given root can be
trusted for EV, or what that root's defined EV OID might be.

The CABF doesn't provide a single platform or source for validation,
auditing, or enforcement.  Everything is related to the browser members,
which themselves are only approached for extended capabilities if they
already have enough market share.  This creates an old-boy's club that
can't easily be broken into.

iOS has its own certificate store, if I remember correctly.  Perhaps Apple
has a means to check the EV status of a root certificate and all of its
intermediaries, as well as the end-entity.

n.b. The rules for verifying and validating EV certificates are complex.
They can be derived from (not specifically found in) the Extended
Validation specification, from CABF.  When last I looked several years ago,
there were OCSP checking, certificate policy chain checking, individual
certificate validity constraints on top of X.509/PKIX overlapping validity
constraints, and several other things that I can't even recall.

-Kyle H


On Mon, May 12, 2014 at 7:59 AM, Steve Behrendt steve.behre...@netlight.com
 wrote:

  Hi everyone,


  I'm building an iOS application and trying to check if a certificate,
 that a https-connection uses, is a EV certificate.


  Does the OpenSSL-libary have a method that gives me that information, if
 a given certificate is a EV certificate?



  I found the method

 X509_get_ext_d2i(certificateX509, NID_certificate_policies, NULL, NULL)

 ​which returns some data depending of the NID provided. Since it is a
 void-pointer, I don't know, which data type it returns.


  Thanks heaps!

 Steve


   Steve Behrendt


 steve.behre...@netlight.com

 Netlight Consulting GmbH www.netlight.de
 Residenzstr. 7, 80333 München
 Mobile +49 160 4729799

 Amtsgericht München, HRB 189944
 Umsatzsteuer-Identifikation: DE276206820
 Geschäftsführer: Felix Sprick

 Please consider the environment before printing this email.

 The information transmitted is intended only for the person or entity to
 which it is addressed and may contain confidential and/or privileged
 material. Any review, retransmission, dissemination or other use of, or
 taking of any action in reliance upon, this information by persons or
 entities other than the intended recipient is prohibited. If you received
 this in error, please contact the sender and delete the material from any
 computer.



Maximum Fragment Length Negotiation RFC 6066

2014-05-12 Thread Simon Wadsworth
Hi,

I am wondering whether there is already some support for the Maximum
Fragment Length Negotiation TLS extension (as specified in RFC 6066). If
not, are there any plans (or is development work underway) for OpenSSL
to support this?

I note in January of last year that there was activity on the
openssl-dev mailing list from Attila Gulyas who had been working on
implementing this functionality and was looking to submit their work. I
however have not been able to find any reference to this work in gitweb,
so am assuming this was never done. Is my assumption here correct?

Thanks,

Simon