Re: Do I need to call BIO_free(network_bio) or not?
May somebody please answer this question? The documentation is
confusing and contradictory, and the issue is important (memory leak
or crash if the bad choice is made).
Thanks.
2014-07-15 14:01 GMT+02:00 Iñaki Baz Castillo i...@aliax.net:
Hi, I'm a bit confused about how to free a BIO pair associated to a SSL.
The doc at https://www.openssl.org/docs/crypto/BIO_s_bio.html clearly says:
Both halves of a BIO pair should be freed. That is even if one half is
implicit freed due to a BIO_free_all() or SSL_free() call the other
half needs to be freed.
EXAMPLE
BIO *internal_bio, *network_bio;
BIO_new_bio_pair(internal_bio, 0, network_bio, 0);
SSL_set_bio(ssl, internal_bio, internal_bio);
...
SSL_free(ssl);/* implicitly frees internal_bio */
BIO_free(network_bio);
Is it true that I must call to BIO_free(network_bio)? The SSL_free()
code seems to do it by itself!:
--
void SSL_free(SSL *s)
{
...
if (s-rbio != NULL)
BIO_free_all(s-rbio);
if ((s-wbio != NULL) (s-wbio != s-rbio))
BIO_free_all(s-wbio);
--
In my code I get an obvious crash if I call BIO_free(internal_bio)
after SSL_free(ssl), but I do NOT get a crash if I call
BIO_free(network_bio).
Anyhow in my code I do not use BIO_new_bio_pair() but instead:
BIO* internal_bio = BIO_new(BIO_s_mem());
BIO* network_bio = BIO_new(BIO_s_mem());
SSL_set_bio(ssl, internal_bio, network_bio);
void destroy() {
if (ssl) {
SSL_free(ssl);
}
// This does NOT crash but, should I do it or not? leak otherwise?
if (write_bio) {
BIO_free(write_bio);
}
}
Thanks a lot.
--
Iñaki Baz Castillo
i...@aliax.net
--
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Do I need to call BIO_free(network_bio) or not?
On Tue, Jul 15, 2014, Iaki Baz Castillo wrote:
Hi, I'm a bit confused about how to free a BIO pair associated to a SSL.
The doc at https://www.openssl.org/docs/crypto/BIO_s_bio.html clearly says:
Both halves of a BIO pair should be freed. That is even if one half is
implicit freed due to a BIO_free_all() or SSL_free() call the other
half needs to be freed.
EXAMPLE
BIO *internal_bio, *network_bio;
BIO_new_bio_pair(internal_bio, 0, network_bio, 0);
SSL_set_bio(ssl, internal_bio, internal_bio);
...
SSL_free(ssl);/* implicitly frees internal_bio */
BIO_free(network_bio);
Is it true that I must call to BIO_free(network_bio)? The SSL_free()
code seems to do it by itself!:
--
void SSL_free(SSL *s)
{
...
if (s-rbio != NULL)
BIO_free_all(s-rbio);
if ((s-wbio != NULL) (s-wbio != s-rbio))
BIO_free_all(s-wbio);
--
In that example SSL_free is calling BIO_free_all() on internal_bio which was
passed using SSL_set_bio().
In my code I get an obvious crash if I call BIO_free(internal_bio)
after SSL_free(ssl), but I do NOT get a crash if I call
BIO_free(network_bio).
Anyhow in my code I do not use BIO_new_bio_pair() but instead:
BIO* internal_bio = BIO_new(BIO_s_mem());
BIO* network_bio = BIO_new(BIO_s_mem());
SSL_set_bio(ssl, internal_bio, network_bio);
Your code uses a doesn't use BIO pairs but the same rule applies. The call to
SSL_free() will call BIO_free_all on the BIO or BIOs passed to SSL_set_bio()
internal_bio and network_bio in this example.
void destroy() {
if (ssl) {
SSL_free(ssl);
}
// This does NOT crash but, should I do it or not? leak otherwise?
if (write_bio) {
BIO_free(write_bio);
}
}
There is no indication of what write_bio is here.
If write_bio is part of a chain involving the BIOs passed to SSL_set_bio() it
will be free up as part of the SSL_free call. If not you need to explicitly
free it yourself.
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
x509v3 Extension: X509v3 Name Constraints?
Hello, does anybody know what to write in the extension config to get this X509v3 Name Constraints as the attached certificate (intel-ca.pem, intel-ca.text)? Thanks. -- Greetings, Walter -BEGIN CERTIFICATE- MIIJWTCCCEGgAwIBAgIQeRdKqRQXNv4Vp8qfLP9FiDANBgkqhkiG9w0BAQUFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF eHRlcm5hbCBDQSBSb290MB4XDTEzMDIwMTAwMDAwMFoXDTIwMDUzMDEwNDgzOFow UjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMScwJQYD VQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDCuISVQi3csKqYk5uz7IOhY8MXkiqBaTqagiht iM997G1mJhTojcR+8DCg3E8OQ3ZajByhxRkwlsR4Srl5sGSwWfF/XaAHGUhWIhjB kDO7toW+EMzI8pAjcLwIbRlIL0AFnUTe6Z0DcIS5406Y/9MKE2oKXbf4EbVBv88m SkA74Z+lZJWFNxXncx/9wq8UdyMY2vHN1Kir1/JbtrqB9wYRBjQtWSbAVZR8nTBP yRp4uvQTS2jOQh+jTUo1Y3O/o1xg/zRA4FEOUCla704OYRUkc8NuXHiPNNDcktr7 gO8E06NVQ6n6aBGaOJbSst2vHA7Eiog7A2PB4wKn+GDFf+FNAgMBAAGjggYMMIIG CDAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUVjpv F6skDOW3MWSwEe3b6iO+XrwwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQEwXgYDVR0lBFcwVQYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI KwYBBQUHAwQGCCsGAQUFBwMIBgorBgEEAYI3CgMEBgorBgEEAYI3CgMMBgkrBgEE AYI3FQUwFwYDVR0gBBAwDjAMBgoqhkiG+E0BBQFpMEkGA1UdHwRCMEAwPqA8oDqG OGh0dHA6Ly9jcmwudHJ1c3QtcHJvdmlkZXIuY29tL0FkZFRydXN0RXh0ZXJuYWxD QVJvb3QuY3JsMIHCBggrBgEFBQcBAQSBtTCBsjBEBggrBgEFBQcwAoY4aHR0cDov L2NydC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5w N2MwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jcnQudHJ1c3QtcHJvdmlkZXIuY29tL0Fk ZFRydXN0VVROU0dDQ0EuY3J0MCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz dC1wcm92aWRlci5jb20wggQXBgNVHR4EggQOMIIECqCCA9QwC4EJaW50ZWwuY29t MAuCCWFwcHVwLmNvbTAOggxjbG91ZG5wby5vcmcwE4IRZWRhY2FkdG9vbGtpdC5v cmcwC4IJZnRsMTAuY29tMAuCCWloY21zLm5ldDAOggxpbmMtbmVzdC5uZXQwFoIU aW5kaWFlZHVzZXJ2aWNlcy5jb20wDYILaW50ZWwuY28uanAwDYILaW50ZWwuY28u a3IwDYILaW50ZWwuY28udWswC4IJaW50ZWwuY29tMAqCCGludGVsLmZyMAuCCWlu dGVsLm5ldDATghFpbnRlbGFsbGlhbmNlLmNvbTAUghJpbnRlbGFwYWNzdG9yZS5j b20wFoIUaW50ZWxhc3NldGZpbmRlci5jb20wGYIXaW50ZWxiZXR0ZXJ0b2dldGhl ci5jb20wFIISaW50ZWxjaGFsbGVuZ2UuY29tMBOCEWludGVsY2xvdWRzc28uY29t MB6CHGludGVsY29uc3VtZXJlbGVjdHJvbmljcy5jb20wEoIQaW50ZWxjb3JlMjAx MC5ydTAWghRpbnRlbGZlbGxvd3NoaXBzLmNvbTAWghRpbnRlbGh5YnJpZGNsb3Vk LmNvbTAUghJpbnRlbHBvcnRmb2xpby5jb20wDoIMaW50ZWwtcmEuY29tMBSCEmlu dGVsLXJlc2VhcmNoLm5ldDAUghJpbnRlbHJtYXN1cnZleS5jb20wGIIWaW50ZWxz bWFsbGJ1c2luZXNzLmNvbTARgg9teWludGVsZWRnZS5jb20wEYIPbXktbGFwdG9w LmNvLnVrMBKCEG9yaWdpbi1hcHB1cC5jb20wHoIcb3JpZ2luLWludGVncmF0aW9u LWFwcHVwLmNvbTAIggZwYy5jb20wFIIScGN0aGVmdGRlZmVuY2UuY29tMBSCEnBj dGhlZnRkZWZlbnNlLmNvbTAOggxwdmF0cmlhbC5uZXQwGYIXcmVkZWZpbmV5b3Vy bmV0d29yay5jb20wD4INcmV0YWlsLWlhLmNvbTAUghJzZXJ2ZXItaW5zaWdodC5j b20wE4IRdGhlaW50ZWxzdG9yZS5jb20wHYIbdGhyZWFkaW5nYnVpbGRpbmdibG9j a3Mub3JnMBuCGXRodW5kZXJib2x0dGVjaG5vbG9neS5uZXQwIIIedWx0cmFib29r LXNvZnR3YXJlLWNvbnRlc3QuY29tMFCkTjBMMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbqEwMAqHCAAAMCKHIAAA MA0GCSqGSIb3DQEBBQUAA4IBAQBYb7/NQwdCE/y40K2BIfKKb++H vCaKfAC9aAwrGWQsEWezqdl5Cqw5XWUAFjtTRm6iprVnmdvov6IlrgSVEQk6L96s tz24vAF0MIBHSFRMoPtrqLiihLf0NOV7ztxSePQxbUJRroe/lKy+lhb7VeV5gmT9 rFA45NzLgSznd2+dmyNcfQQD9AeeftRX4maUTeu1XFxinowtg+ZGFOKhE4D92uCG JxGSK72HF0/LGRhLXozmDdmPfSN2b6T/oLo942031iY46BqcI5LIVh8aGo4A1jOm a5X6gh50Cw+kht8jM3yeNhSzXOKj7Uigjijx10z2wJu09Tyj5ahjoiwIpdX+ -END CERTIFICATE-Certificate: Data: Version: 3 (0x2) Serial Number: 79:17:4a:a9:14:17:36:fe:15:a7:ca:9f:2c:ff:45:88 Signature Algorithm: sha1WithRSAEncryption Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root Validity Not Before: Feb 1 00:00:00 2013 GMT Not After : May 30 10:48:38 2020 GMT Subject: C=US, O=Intel Corporation, CN=Intel External Basic Policy CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c2:b8:84:95:42:2d:dc:b0:aa:98:93:9b:b3:ec: 83:a1:63:c3:17:92:2a:81:69:3a:9a:82:28:6d:88: cf:7d:ec:6d:66:26:14:e8:8d:c4:7e:f0:30:a0:dc: 4f:0e:43:76:5a:8c:1c:a1:c5:19:30:96:c4:78:4a: b9:79:b0:64:b0:59:f1:7f:5d:a0:07:19:48:56:22: 18:c1:90:33:bb:b6:85:be:10:cc:c8:f2:90:23:70: bc:08:6d:19:48:2f:40:05:9d:44:de:e9:9d:03:70: 84:b9:e3:4e:98:ff:d3:0a:13:6a:0a:5d:b7:f8:11: b5:41:bf:cf:26:4a:40:3b:e1:9f:a5:64:95:85:37: 15:e7:73:1f:fd:c2:af:14:77:23:18:da:f1:cd:d4: a8:ab:d7:f2:5b:b6:ba:81:f7:06:11:06:34:2d:59: 26:c0:55:94:7c:9d:30:4f:c9:1a:78:ba:f4:13:4b: 68:ce:42:1f:a3:4d:4a:35:63:73:bf:a3:5c:60:ff:
Re: Do I need to call BIO_free(network_bio) or not?
2014-07-17 14:29 GMT+02:00 Dr. Stephen Henson st...@openssl.org: Your code uses a doesn't use BIO pairs but the same rule applies. The call to SSL_free() will call BIO_free_all on the BIO or BIOs passed to SSL_set_bio() internal_bio and network_bio in this example. Thanks. Then the example in the documentation is really wrong and may cause a crash, right? I mean the BIO_free(network_bio); line at the end. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: x509v3 Extension: X509v3 Name Constraints?
Hello. I am looking for advice for designing the transmit/receive network module of my application using openSSL. I originally designed the application using two threads, a transmit thread and a receive thread. These threads relied on a single BIO that was set for blocking more that would connect to the server and remain connected as long as possible. If a disconnection was detected, it would reconnect. However, this design has some drawbacks. From what I've read, despite having implemented the locking mechanism for the library, I now realize that a single BIO within an application is not thread safe. This may be an underlying cause of communication failures that crops up after long periods of run-time. It's hard to predict when a failure will occur, but it seems as though neither thread makes progress when it happens. My receiver thread was responsible for keeping the connection and reading data from the BIO. The transmitter would continue to try and transmit data received in a posix mqueue when the socket while connected. Is there a better pattern to use? From what I have read, I could switch to a single thread and create an underlying non-blocking socket that is bound to an SSL. I could also read transmit data from the existing queue, but set it for non-blocking. However, the details of how the library works in non-blocking more are still a bit fuzzy. When WANT_READ is returned, does this mean one should select on write and perform whichever operation (read or write) caused the error? If WANT_WRITE is returned, should I select on read and perform the previous operation? Can someone please outline clearly what steps to take for each return value for both read/write operations. Perhaps there is an opportunity to improve the OpenSSL documentation since I see questions like this in the mailing list frequently. Thank you in advance. --Eric On Thu, Jul 17, 2014 at 1:57 PM, Walter H. walte...@mathemainzel.info wrote: Hello, does anybody know what to write in the extension config to get this X509v3 Name Constraints as the attached certificate (intel-ca.pem, intel-ca.text)? Thanks. -- Greetings, Walter
s_client CKE protocol version is wrong?
Hi all,
I have a confusion for s_client CKE premaster protocol version.
Can somebody help to explain it? Thanks!
I add -DSSL_DEBUG to do debug output when compiling.
Below is my test result:
Server side:
$./openssl s_server -tls1 (server only accept TLSv1 connection)
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
Premaster Secret:
- 03 03 bd b0 7c d3 65 1b-9c f2 80 91 f7 f3 74 b0 |.e...t.
--- 03 03(TLSv12)
0010 - 47 f4 5c fe f2 d4 68 b1-fc 74 75 53 7a 45 34 d4 G.\...h..tuSzE4.
0020 - 24 56 0f 3c af 8d bf bb-1e 4f af 83 8b 46 f0 8f $V..O...F..
Client Random:
- a7 17 2c 08 39 2f ae b5-51 3e 7e 6c 95 46 a9 53 ..,.9/..Q~l.F.S
0010 - 2a 84 1a a8 db b4 f6 94-d9 91 8a e3 99 5c 5a 97 *\Z.
Server Random:
- eb b2 e3 f8 7d fb b1 a3-75 e1 05 2b 5d 9f 25 03 }...u..+].%.
0010 - 29 73 2e 61 87 47 95 05-3d f3 f7 75 8f 6b 16 82 )s.a.G..=..u.k..
Master Secret:
- 2d 42 3b a2 30 b6 49 60-9f 37 87 5d ee 75 f1 18 -B;.0.I`.7.].u..
0010 - 0b 7b b8 b7 6d 2b 60 7c-70 44 f7 00 e2 2e 57 e0 .{..m+`|pDW.
0020 - e6 a0 8b 0b f7 5b a0 6c-26 23 3b 91 4c b8 c8 8e .[.l#;.L...
Client side:
$ ./openssl s_client -connect 10.8.2.150:4433 -cipher RC4-SHA
CONNECTED(0003)
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN =
Test Server Cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN =
Test Server Cert
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN =
Test Server Cert
verify error:num=21:unable to verify the first certificate
verify return:1
Premaster Secret:
- 03 03 bd b0 7c d3 65 1b-9c f2 80 91 f7 f3 74 b0 |.e...t.
--- 03 03(TLSv12) wrong?
0010 - 47 f4 5c fe f2 d4 68 b1-fc 74 75 53 7a 45 34 d4 G.\...h..tuSzE4.
0020 - 24 56 0f 3c af 8d bf bb-1e 4f af 83 8b 46 f0 8f $V..O...F..
Client Random:
- a7 17 2c 08 39 2f ae b5-51 3e 7e 6c 95 46 a9 53 ..,.9/..Q~l.F.S
0010 - 2a 84 1a a8 db b4 f6 94-d9 91 8a e3 99 5c 5a 97 *\Z.
Server Random:
- eb b2 e3 f8 7d fb b1 a3-75 e1 05 2b 5d 9f 25 03 }...u..+].%.
0010 - 29 73 2e 61 87 47 95 05-3d f3 f7 75 8f 6b 16 82 )s.a.G..=..u.k..
Master Secret:
- 2d 42 3b a2 30 b6 49 60-9f 37 87 5d ee 75 f1 18 -B;.0.I`.7.].u..
0010 - 0b 7b b8 b7 6d 2b 60 7c-70 44 f7 00 e2 2e 57 e0 .{..m+`|pDW.
0020 - e6 a0 8b 0b f7 5b a0 6c-26 23 3b 91 4c b8 c8 8e .[.l#;.L...
. certificate ignore .
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
LOCAL PORT is 41469
SSL-Session:
Protocol : TLSv1--Negotiating TLSv1(03
01) as protocol version.
Cipher: RC4-SHA
Session-ID:
FA52422FEE594293111ABAB10129DCA3B8FB74F5958827FDD447DC657A08E6E3
Session-ID-ctx:
Master-Key:
2D423BA230B649609F37875DEE75F1180B7BB8B76D2B607C7044F700E22E57E0E6A08B0BF75BA06C26233B914CB8C88E
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
- f0 89 3c ab 06 fc de cc-0f 94 cf be 2d 44 0d 25
...-D.%
0010 - fb 08 8f 48 8b 18 07 a1-46 ab fd 8b 02 82 68 a3
...HF.h.
0020 - 0e f2 f6 6a d7 55 6b 0b-dd ed 8f ec ad 17 bb 3c
...j.Uk
0030 - 09 67 05 ae 77 45 0f a2-df de 33 b6 df 8d a4 92
.g..wE3.
0040 - 02 8d a0 0b 22 be 26 a4-21 51 ff f9 9d dc 60 7b
..!Q`{
0050 - bb d3 c6 db e7 2e 54 11-8d 3c f3 0c 53 89 de 0d
..TS...
0060 - 1f 6e 50 b5 05 d2 7e ec-48 75 42 42 10 ba 89 37
.nP...~.HuBB...7
0070 - d6 62 5c c1 34 1c b3 0e-ba f8 46 13 05 13 bf fe
.b\.4.F.
0080 - 54 2f 36 f5 d2 7c cf 92-43 2d 3b 3b c0 f7 f0 2d
T/6..|..C-;;...-
0090 - 3d 58 a9 0c 98 c3 ed b6-37 b7 18 31 76 e8 40 c5 =X..7..1v.@
.
Start Time: 1405567904
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
--
Best Regards,
-
Gao Jinjun
MSN: gjin...@gmail.com
testlog
Description: Binary data
Default digest implementation?
https://www.openssl.org/docs/crypto/EVP_DigestInit.html
The doc states the default default digest implementation is used if
'impl' is NULL. The docs also state OpenSSL 1.0 and later does not
include the MD2 digest algorithm in the default configuration
I found the call to EVP_DigestInit which calls EVP_DigestInit_ex. But
I'm getting lost in EVP_DigestInit_ex:
if(impl)
{
...
}
else
{
/* Ask if an ENGINE is reserved for this job */
impl = ENGINE_get_digest_engine(type-type);
}
I'm having trouble tracking down 'type' used by ENGINE_get_digest_engine.
What is the default digest implementation for 1.0 and later? Or where
can I find the source file that sets the default?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
