[openssl-users] SSL_shutdown:shutdown while in init

[Chris Bare]

I have the following code:

setup_ssl (char *server_name, char *port, SSL_CTX *ctx)
{
BIO *output = BIO_new_ssl_connect (ctx);
if (!output)
{
return (NULL);
}
BIO_get_ssl (output, &ssl);
SSL_set_mode (ssl, SSL_MODE_AUTO_RETRY);
SSL_set_verify (ssl, true, NULL);
BIO_set_conn_hostname (output, server_name);
BIO_set_conn_port(output, port);

if (BIO_do_connect (output) <= 0)
{
BIO_free (output);
return (NULL);
}
}

If the server I'm trying to connect to does not have ssl enabled, I get the
error:
SSL23_GET_SERVER_HELLO:unknown protocol
and BIO_do_connect fails as expected, but BIO_free gives this error:
SSL_shutdown:shutdown while in init

If I don't free it, I have a memory leak.
Is there something else I need to do to clean up the BIO?
I tried calling BIO_do_handshake, but that crashes (not surprised).

-- 
Chris Bare
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue with freeing X509

[Adi Mallikarjuna Reddy V]

Since I tried all that and it crashes, I am going ahead and giving you the
more details on how I created *cert/evp_pkey* objects.


*X509 *cert =  PEM_read_bio_X509_AUX(cert_bio, NULL, NULL, NULL);*

*EVP_PKEY *evp_pkey = PEM_read_bio_PrivateKey(key_bio, NULL, NULL, NULL);*

I tried freeing both *cert* and *evp_pkey* locally before even I use
SSL_Ctx object and after using it and freeing using SSL_CTx_Free(ctx). Both
results in a signal 11 crash.


*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(i2c_ASN1_INTEGER+0x10)[0x2b6a4a09d2b0]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(asn1_ex_i2c+0x119)[0x2b6a4a0a8269]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(+0x13835f)[0x2b6a4a0a835f]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_ex_i2d+0x127)[0x2b6a4a0a85d7]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(+0x138b51)[0x2b6a4a0a8b51]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_ex_i2d+0x270)[0x2b6a4a0a8720]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(+0x138bdd)[0x2b6a4a0a8bdd]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_ex_i2d+0x270)[0x2b6a4a0a8720]*
*/opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_i2d+0x4b)[0x2b6a4a0a8ebb]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(+0x463db)[0x2b6a49d473db]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl_add_cert_chain+0xb1)[0x2b6a49d47551]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl3_output_cert_chain+0x28)[0x2b6a49d2dc88]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl3_send_server_certificate+0x3d)[0x2b6a49d1b2bd]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl3_accept+0xfe8)[0x2b6a49d206b8]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl23_get_client_hello+0x94)[0x2b6a49d2f984]*
*/opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl23_accept+0xa1)[0x2b6a49d30251]*





On Tue, Oct 17, 2017 at 11:37 AM, Benjamin Kaduk  wrote:

> I thought this had become documented recently (i.e., in master only, not
> even in 1.1.0), but can't find any evidence of such documentation.
>
> SSL_CTX_use_PrivateKey() takes a reference on its pkey argument in the
> same way as SSL_CTX_use_certificate(); it is safe for the local code to
> free its local copy.
>
> -Ben
>
> On 10/17/2017 12:32 PM, Adi Mallikarjuna Reddy V wrote:
>
> Is this documented some where?
>
> Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ? where
> I can free evp_pkey with EVP_PKEY_free()?
>
>
> Thanks
> Adi
>
> On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk  wrote:
>
>> On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote:
>>
>> I am only worried about the following line.
>>
>> SSL_CTX_use_certificate(ctx, cert)
>>
>> After this line is it safe to free cert object while ctx is still used
>> later on?
>>
>>
>> SSL_CTX_use_certificate(ctx, cert), on successful return, takes an
>> additional reference on the supplied |cert| argument to account for the
>> pointer in |ctx|.  Thus, the caller of SSL_CTX_use_certificate() can safely
>> call X509_free(cert) to release the caller's local reference, while the
>> |ctx| retains a pointer to |cert|.
>>
>> -Ben
>>
>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

I thought this had become documented recently (i.e., in master only, not
even in 1.1.0), but can't find any evidence of such documentation.

SSL_CTX_use_PrivateKey() takes a reference on its pkey argument in the
same way as SSL_CTX_use_certificate(); it is safe for the local code to
free its local copy.

-Ben

On 10/17/2017 12:32 PM, Adi Mallikarjuna Reddy V wrote:
> Is this documented some where? 
>
> Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ?
> where I can free evp_pkey with EVP_PKEY_free()?
>
>
> Thanks
> Adi
>
> On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk  > wrote:
>
> On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote:
>>> I am only worried about the following line. 
>>>
>>> SSL_CTX_use_certificate(ctx, cert)
>>>
>>> After this line is it safe to free cert object while ctx is
>>> still used later on?
>>>
>
> SSL_CTX_use_certificate(ctx, cert), on successful return, takes an
> additional reference on the supplied |cert| argument to account
> for the pointer in |ctx|.  Thus, the caller of
> SSL_CTX_use_certificate() can safely call X509_free(cert) to
> release the caller's local reference, while the |ctx| retains a
> pointer to |cert|.
>
> -Ben
>
>

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

Re: [openssl-users] Issue with freeing X509

[Adi Mallikarjuna Reddy V]

Is this documented some where?

Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ? where
I can free evp_pkey with EVP_PKEY_free()?


Thanks
Adi

On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk  wrote:

> On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote:
>
> I am only worried about the following line.
>
> SSL_CTX_use_certificate(ctx, cert)
>
> After this line is it safe to free cert object while ctx is still used
> later on?
>
>
> SSL_CTX_use_certificate(ctx, cert), on successful return, takes an
> additional reference on the supplied |cert| argument to account for the
> pointer in |ctx|.  Thus, the caller of SSL_CTX_use_certificate() can safely
> call X509_free(cert) to release the caller's local reference, while the
> |ctx| retains a pointer to |cert|.
>
> -Ben
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote:
>> I am only worried about the following line. 
>>
>> SSL_CTX_use_certificate(ctx, cert)
>>
>> After this line is it safe to free cert object while ctx is still
>> used later on?
>>

SSL_CTX_use_certificate(ctx, cert), on successful return, takes an
additional reference on the supplied |cert| argument to account for the
pointer in |ctx|.  Thus, the caller of SSL_CTX_use_certificate() can
safely call X509_free(cert) to release the caller's local reference,
while the |ctx| retains a pointer to |cert|.

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue with freeing X509

[Adi Mallikarjuna Reddy V]

I am only worried about the following line.

SSL_CTX_use_certificate(ctx, cert)

After this line is it safe to free cert object while ctx is still used
later on?

Thanks
Adi

On Tue, Oct 17, 2017 at 9:21 AM Benjamin Kaduk  wrote:

> You only asked about freeing the X509, which is safe in this situation.
>
> It is not safe to free the SSL_CTX if you want to use it again later --
> remove this SSL_CTX_free(ctx) call and put one in your program's cleanup
> instead.
>
> -Ben
>
> On 10/17/2017 11:08 AM, Adi Mallikarjuna Reddy V wrote:
>
> Forgot to mention that the ssl_ctx is going to be used by another thread
> later. When I do x509_free, the handshake doesn’t finish.
>
> I see a crash in ssl_accept.
>
> Thanks
> Adi
>
> On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk  wrote:
>
>> On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote:
>>
>> Hi,
>>
>> If I have an X509 object and is created using PEM_read_bio_X509_AUX(),
>> then Can I free X509 right after the completion of PEM_read_bio_X509_AUX()?
>>
>>BIO *cert_bio = BIO_new(BIO_s_mem());
>> X509 *cert = X509_new();
>> BIO_puts(cert_bio, cert_str.c_str());
>> cert = PEM_read_bio_X509_AUX(cert_bio,
>> &cert, NULL, NULL);
>> if ( (cert != NULL) &&
>> SSL_CTX_use_certificate(ctx, cert) < 1) {
>> SSL_CTX_free(ctx);
>>
>>
>> Yes.
>>
>> -Ben
>>
>>
>> return NULL;
>> }
>>
>> if(cert_bio !=NULL) {
>> BIO_free(cert_bio);
>> }
>> if(cert != NULL) {
>> X509_free(cert); //is it needed?
>> }
>>
>>
>> Thanks
>> Adi
>>
>>
>>
>> --
> Sent from Mobile
>
>
> --
Sent from Mobile
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

You only asked about freeing the X509, which is safe in this situation.

It is not safe to free the SSL_CTX if you want to use it again later --
remove this SSL_CTX_free(ctx) call and put one in your program's cleanup
instead.

-Ben

On 10/17/2017 11:08 AM, Adi Mallikarjuna Reddy V wrote:
> Forgot to mention that the ssl_ctx is going to be used by another
> thread later. When I do x509_free, the handshake doesn’t finish.
>
> I see a crash in ssl_accept.
>
> Thanks 
> Adi
>
> On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk  > wrote:
>
> On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote:
>> Hi,
>>
>> If I have an X509 object and is created
>> using PEM_read_bio_X509_AUX(), then Can I free X509 right after
>> the completion of PEM_read_bio_X509_AUX()?
>>
>>                                BIO *cert_bio = BIO_new(BIO_s_mem());
>>                                 X509 *cert = X509_new();
>>                                 BIO_puts(cert_bio, cert_str.c_str());
>>                                 cert =
>> PEM_read_bio_X509_AUX(cert_bio, &cert, NULL, NULL);
>>                                 if ( (cert != NULL) &&
>> SSL_CTX_use_certificate(ctx, cert) < 1) {
>>                                         SSL_CTX_free(ctx);
>
> Yes.
>
> -Ben
>
>
>>                                         return NULL;
>>                                 }
>>                                
>>                                 if(cert_bio !=NULL) {
>>                                         BIO_free(cert_bio);
>>                                 }
>>                                 if(cert != NULL) {
>>                                         X509_free(cert); //is it
>> needed?
>>                                 }
>>
>>
>> Thanks
>> Adi
>>
>>
>
> -- 
> Sent from Mobile

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

Re: [openssl-users] Issue with freeing X509

[Adi Mallikarjuna Reddy V]

Forgot to mention that the ssl_ctx is going to be used by another thread
later. When I do x509_free, the handshake doesn’t finish.

I see a crash in ssl_accept.

Thanks
Adi

On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk  wrote:

> On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote:
>
> Hi,
>
> If I have an X509 object and is created using PEM_read_bio_X509_AUX(),
> then Can I free X509 right after the completion of PEM_read_bio_X509_AUX()?
>
>BIO *cert_bio = BIO_new(BIO_s_mem());
> X509 *cert = X509_new();
> BIO_puts(cert_bio, cert_str.c_str());
> cert = PEM_read_bio_X509_AUX(cert_bio,
> &cert, NULL, NULL);
> if ( (cert != NULL) &&
> SSL_CTX_use_certificate(ctx, cert) < 1) {
> SSL_CTX_free(ctx);
>
>
> Yes.
>
> -Ben
>
>
> return NULL;
> }
>
> if(cert_bio !=NULL) {
> BIO_free(cert_bio);
> }
> if(cert != NULL) {
> X509_free(cert); //is it needed?
> }
>
>
> Thanks
> Adi
>
>
>
> --
Sent from Mobile
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote:
> Hi,
>
> If I have an X509 object and is created using PEM_read_bio_X509_AUX(),
> then Can I free X509 right after the completion
> of PEM_read_bio_X509_AUX()?
>
>                                BIO *cert_bio = BIO_new(BIO_s_mem());
>                                 X509 *cert = X509_new();
>                                 BIO_puts(cert_bio, cert_str.c_str());
>                                 cert = PEM_read_bio_X509_AUX(cert_bio,
> &cert, NULL, NULL);
>                                 if ( (cert != NULL) &&
> SSL_CTX_use_certificate(ctx, cert) < 1) {
>                                         SSL_CTX_free(ctx);

Yes.

-Ben

>                                         return NULL;
>                                 }
>                                
>                                 if(cert_bio !=NULL) {
>                                         BIO_free(cert_bio);
>                                 }
>                                 if(cert != NULL) {
>                                         X509_free(cert); //is it needed?
>                                 }
>
>
> Thanks
> Adi
>
>

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

[openssl-users] Issue with freeing X509

[Adi Mallikarjuna Reddy V]

Hi,

If I have an X509 object and is created using PEM_read_bio_X509_AUX(), then
Can I free X509 right after the completion of PEM_read_bio_X509_AUX()?

   BIO *cert_bio = BIO_new(BIO_s_mem());
X509 *cert = X509_new();
BIO_puts(cert_bio, cert_str.c_str());
cert = PEM_read_bio_X509_AUX(cert_bio,
&cert, NULL, NULL);
if ( (cert != NULL) &&
SSL_CTX_use_certificate(ctx, cert) < 1) {
SSL_CTX_free(ctx);
return NULL;
}

if(cert_bio !=NULL) {
BIO_free(cert_bio);
}
if(cert != NULL) {
X509_free(cert); //is it needed?
}


Thanks
Adi
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] DSA2048 support in openssl-fips-2.0.14.

[Manjunath SM]

Hi All,
Am using openssl-fips-2.0.14 at server side on top of openssl1.0.2K.
Server is operating in FIPS mode(fips mode enabled thru FIPS_mode_set).

Created DSA2048 host key at server which is running in FIPS mode,
With this configuration when am trying to do SSH from ssh client am getting
below error.
===

The authenticity of host '135.249.23.182 (135.249.23.182)' can't be
established
but keys of different type are already known for this host.
DSA key fingerprint is 31:75:2c:96:ac:9c:11:f8:3b:39:0b:86:ba:88:51:02.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '135.249.23.182' (DSA) to the list of known
hosts.

*ssh_dss_verify: remaining bytes in signature 24key_verify failed for
server_host_key*


SSH client version is
 OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013


In FIPS use guide  doI see, DSA 2048 is supported.
Does any one faced similar issue ?If so pls share the findings.

-- 
--
Regards
Manju
--
“Take care of the earth and she will take care of you.”
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query on API availability for openssl versions

[Matt Caswell]

On 17/10/17 10:01, Grace Priscilla Jero wrote:
> Thank you Matt for the quick response.
> For "2," does it mean that every cipher suite can operate in multiple
> levels? 
> I thought that there were specific set of cipher suites operating in
> each of the levels.

Not quite. The security levels look at the amount of security you can
expect from all the algorithms in a ciphersuite.

I dug out this description I had in a document (not checked to see if
this is completely current (it was written a couple of years ago while
1.1.0 was still in development), but you get the idea):

• Level 0: No restrictions
• Level 1: 80 bits of security. Encryption algorithms with less than 80
security bits will be excluded, as will RSA, DSA and DH keys shorter
than 1024 bits and ECC keys less than 160 bits in length. Also
prohibited is any ciphersuite based on MD5 for its MAC.
• Level 2: 112 bits of security. Encryption algorithms with less than
112 security bits will be excluded, as will RSA, DSA and DH keys shorter
than 2048 bits and ECC keys less than 224 bits in length. Additionally
MD5 based MACs, SSLv3 and compression are prohibited.
• Level 3: 128 bits of security. Encryption algorithms with less than
128 security bits will be excluded, as will RSA, DSA and DH keys shorter
than 3072 bits and ECC keys less than 256 bits in length. Additionally
MD5, SSLv3, TLSv1.0, compression and session tickets are prohibited.
• Level 4: 192 bits of security. Encryption algorithms with less than
192 security bits will be excluded, as will RSA, DSA and DH keys shorter
than 7680 bits and ECC keys less than 384 bits in length. Additionally
MD5 or SHA1 based MACs, SSLv3, TLSv1.0, TLSv1.1, compression and session
tickets are prohibited.
• Level 5: 256 bits of security. Encryption algorithms with less than
256 security bits will be excluded, as will RSA, DSA and DH keys shorter
than 15360 bits and ECC keys less than 512 bits in length. Additionally
MD5 or SHA1 based MACs, SSLv3, TLSv1.0, TLSv1.1, compression and
session tickets are prohibited.

This may mean that an individual ciphersuite is excluded completely by a
security level, or it might mean it just has restrictions on the key
lengths that are acceptable to use with it.

Matt


> 
> Thanks,
> Grace
> 
> On Tue, Oct 17, 2017 at 2:25 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 17/10/17 09:21, Grace Priscilla Jero wrote:
> > Hi All,
> >
> > 1)
> > The below APIs used to set the maximum and minimum versions are
> > available in 1.1.0f version of OPENSSL.
> >
> >  int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
> >  int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version);
> >  int SSL_set_min_proto_version(SSL *ssl, int version);
> >  int SSL_set_max_proto_version(SSL *ssl, int version);
> >
> >  Do you have the same in any of the 1.0.2x threads or plan to have it in
> > any later versions. We don't see it available in 1.0.2k or 1.0.2l
> > versions. Kindly update us on the same.
> 
> These APIs were first introduced into 1.1.0, and we intend to continue
> to support them moving forward in future versions. However they will not
> be backported to the 1.0.2 branch. We do not add new features to a
> stable branch.
> 
> In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1,
> SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the SSL_CTX_set_options() or
> SSL_set_options() functions.
> 
> 
> >
> > 2)
> > There are a set of APIs to set/get security level wherein each level
> > supports a set of cipher suites. Is there something available in OPENSSL
> > wherein I can get the level and set it when I provide a cipher suite.
> > We have a case where we give the user a provision to provide his own
> > list of cipher suites and we need to set the appropriate level in the
> > API so that we support it for the connections. Kindly provide your 
> comments.
> 
> You can set the security level via the cipher string using the special
> cipher string command "@SECLEVEL". For example to set all default
> ciphersuites at security level 2 or above you can use:
> 
> "DEFAULT:@SECLEVEL=2"
> 
> Matt
> 
> --
> openssl-users mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query on API availability for openssl versions

[Jakob Bohm]

The security levels are simply a classification of the cipher
suites by quality.  Typically one would select all ciphers above
a certain level.

Most cipher suites work with all protocol levels >= a certain
level, with SSL2 (dead) and TLS1.3 (future) being exceptions.
Selecting something like "TLS1.1" in the cipher suite list simply
selects those cipher suites that were new in TLS1.1, it does not
actually select the TLS1.1 protocol.

On 17/10/2017 11:01, Grace Priscilla Jero wrote:

Thank you Matt for the quick response.
For "2," does it mean that every cipher suite can operate in multiple 
levels?
I thought that there were specific set of cipher suites operating in 
each of the levels.


Thanks,
Grace

On Tue, Oct 17, 2017 at 2:25 PM, Matt Caswell > wrote:




On 17/10/17 09:21, Grace Priscilla Jero wrote:
> Hi All,
>
> 1)
> The below APIs used to set the maximum and minimum versions are
> available in 1.1.0f version of OPENSSL.
>
>  int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
>  int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version);
>  int SSL_set_min_proto_version(SSL *ssl, int version);
>  int SSL_set_max_proto_version(SSL *ssl, int version);
>
>  Do you have the same in any of the 1.0.2x threads or plan to
have it in
> any later versions. We don't see it available in 1.0.2k or 1.0.2l
> versions. Kindly update us on the same.

These APIs were first introduced into 1.1.0, and we intend to continue
to support them moving forward in future versions. However they
will not
be backported to the 1.0.2 branch. We do not add new features to a
stable branch.

In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1,
SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the
SSL_CTX_set_options() or
SSL_set_options() functions.


>
> 2)
> There are a set of APIs to set/get security level wherein each level
> supports a set of cipher suites. Is there something available in
OPENSSL
> wherein I can get the level and set it when I provide a cipher
suite.
> We have a case where we give the user a provision to provide his own
> list of cipher suites and we need to set the appropriate level
in the
> API so that we support it for the connections. Kindly provide
your comments.

You can set the security level via the cipher string using the special
cipher string command "@SECLEVEL". For example to set all default
ciphersuites at security level 2 or above you can use:

"DEFAULT:@SECLEVEL=2"



--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 


This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query on API availability for openssl versions

[Grace Priscilla Jero]

Thank you Matt for the quick response.
For "2," does it mean that every cipher suite can operate in multiple
levels?
I thought that there were specific set of cipher suites operating in each
of the levels.

Thanks,
Grace

On Tue, Oct 17, 2017 at 2:25 PM, Matt Caswell  wrote:

>
>
> On 17/10/17 09:21, Grace Priscilla Jero wrote:
> > Hi All,
> >
> > 1)
> > The below APIs used to set the maximum and minimum versions are
> > available in 1.1.0f version of OPENSSL.
> >
> >  int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
> >  int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version);
> >  int SSL_set_min_proto_version(SSL *ssl, int version);
> >  int SSL_set_max_proto_version(SSL *ssl, int version);
> >
> >  Do you have the same in any of the 1.0.2x threads or plan to have it in
> > any later versions. We don't see it available in 1.0.2k or 1.0.2l
> > versions. Kindly update us on the same.
>
> These APIs were first introduced into 1.1.0, and we intend to continue
> to support them moving forward in future versions. However they will not
> be backported to the 1.0.2 branch. We do not add new features to a
> stable branch.
>
> In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1,
> SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the SSL_CTX_set_options() or
> SSL_set_options() functions.
>
>
> >
> > 2)
> > There are a set of APIs to set/get security level wherein each level
> > supports a set of cipher suites. Is there something available in OPENSSL
> > wherein I can get the level and set it when I provide a cipher suite.
> > We have a case where we give the user a provision to provide his own
> > list of cipher suites and we need to set the appropriate level in the
> > API so that we support it for the connections. Kindly provide your
> comments.
>
> You can set the security level via the cipher string using the special
> cipher string command "@SECLEVEL". For example to set all default
> ciphersuites at security level 2 or above you can use:
>
> "DEFAULT:@SECLEVEL=2"
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query on API availability for openssl versions

[Matt Caswell]

On 17/10/17 09:21, Grace Priscilla Jero wrote:
> Hi All,
> 
> 1)
> The below APIs used to set the maximum and minimum versions are
> available in 1.1.0f version of OPENSSL.
> 
>  int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
>  int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version);
>  int SSL_set_min_proto_version(SSL *ssl, int version);
>  int SSL_set_max_proto_version(SSL *ssl, int version);
> 
>  Do you have the same in any of the 1.0.2x threads or plan to have it in
> any later versions. We don't see it available in 1.0.2k or 1.0.2l
> versions. Kindly update us on the same.

These APIs were first introduced into 1.1.0, and we intend to continue
to support them moving forward in future versions. However they will not
be backported to the 1.0.2 branch. We do not add new features to a
stable branch.

In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1,
SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the SSL_CTX_set_options() or
SSL_set_options() functions.


> 
> 2)
> There are a set of APIs to set/get security level wherein each level
> supports a set of cipher suites. Is there something available in OPENSSL
> wherein I can get the level and set it when I provide a cipher suite.
> We have a case where we give the user a provision to provide his own
> list of cipher suites and we need to set the appropriate level in the
> API so that we support it for the connections. Kindly provide your comments.

You can set the security level via the cipher string using the special
cipher string command "@SECLEVEL". For example to set all default
ciphersuites at security level 2 or above you can use:

"DEFAULT:@SECLEVEL=2"

Matt

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

[openssl-users] Query on API availability for openssl versions

[Grace Priscilla Jero]

Hi All,

1)
The below APIs used to set the maximum and minimum versions are available
in 1.1.0f version of OPENSSL.

 int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
 int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version);
 int SSL_set_min_proto_version(SSL *ssl, int version);
 int SSL_set_max_proto_version(SSL *ssl, int version);

 Do you have the same in any of the 1.0.2x threads or plan to have it in
any later versions. We don't see it available in 1.0.2k or 1.0.2l versions.
Kindly update us on the same.

2)
There are a set of APIs to set/get security level wherein each level
supports a set of cipher suites. Is there something available in OPENSSL
wherein I can get the level and set it when I provide a cipher suite.
We have a case where we give the user a provision to provide his own list
of cipher suites and we need to set the appropriate level in the API so
that we support it for the connections. Kindly provide your comments.

Thanks,
Grace
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users