Re: [openssl-users] Trying to understand DTLS (as it applies to webrtc)
Matt, Sorry for the confusion. In the first (correct) trace the client is BoringSSL (webrtc) and the server hello comes from Janus (OpenSSL). In the bad trace the Client is openSSL and the server is BoringSSL. The error almost always seems to happen in this configuration (when client == openSSL, Server == BoringSSL) So im guessing the client hello is different since it comes from boring SSL. I'm currently testing janus with both 1.0.1m and BoringSSL (same version as webrtc/chrome M43). I'll post my results if it doesnt end up in the same state in a few days as I get some testing on these servers! This has been amazing helpful. OpenSSL seems DTLS handshakes seem so easy :) I cant believe theres a SSL_do_handshake() function! Thank you! On Fri, May 1, 2015 at 3:41 PM Matt Caswell m...@openssl.org wrote: On 01/05/15 02:11, faraz khan wrote: Hi everyone, This is my first time posting to this list - so if theres a better place for this question please let me know. The problem I'm trying to fix applies to the Janus webrtc gateway (https://github.com/meetecho/janus-gateway) and my application which is using native C++ webrtc. What happens is that after hundreds of successful connections, sometimes the Janus server is unable to negotiate a DTLS handshake and after a key exchange the webrtc client replied with a DTLS Alert: Decrypt failed message. I'm attaching a wireshark trace of the issue happening and one for the correct negotiation. Can you confirm that the trace you attached for the correct negotiation also came from Janus? I spotted some odd things about the extensions in the ClientHello: It has the extended master secret extension. That extension is not supported by any released version of OpenSSL (we have it in the dev version of 1.1.0 - but that is unreleased). It correctly adds the ec_point_formats and elliptic_curves extensions. However it so happens that OpenSSL 1.0.1f has a bug in it (not in the latest version) which suppresses those extensions for DTLS (this is a significant enough bug in itself that it is worthwhile upgrading your OpenSSL) OpenSSL always adds extensions in the same order - and these extensions are in a different order. Due to the above it looks to me like the OpenSSL DTLS stack was not used to generate that ClientHello. The failed one *does* look like an OpenSSL generated ClientHello. 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] Performance problems with OpenSSL and threading
Yes, if you never call FIPS_mode_set(), the POST will never run. I'll
defer to the experts on your other questions.
On 05/01/2015 05:10 PM, Bryan Call wrote:
So can I assume the FIPS POST has completed if I never call FIPS_mode_set()
in the code? I was confused about that.
When we call SSL_read() and get a 0 byte return we call SSL_get_error() to
see if there was an error not not. Maybe there is a more efficient handle
this, like looking at the shutdown flag?
0 The read operation was not successful. The reason may either be a
clean shutdown due to a close notify alert sent by the peer (in
which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
possible, that the peer simply shut down the underlying transport
and the shutdown is incomplete. Call SSL_get_error() with the
return value ret to find out, whether an error occurred or the
connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).
When we call SSL_accept we also call SSL_get_error() to see we need to read
or write. Is there a more efficient way to tell if we need to read or write?
If the underlying BIO is non-blocking, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept() to
continue the handshake, indicating the problem by the return value -1.
In this case a call to SSL_get_error() with the return value of
SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The calling process then must repeat the call after taking appropriate
action to satisfy the needs of SSL_accept(). The action depends on the
underlying BIO. When using a non-blocking socket, nothing is to be
done, but select() can be used to check for the required condition.
When using a buffering BIO, like a BIO pair, data must be written into
or retrieved out of the BIO before being able to continue.
Thank you...
-Bryan
On May 1, 2015, at 5:34 AM, John Foley fol...@cisco.com wrote:
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It
appears your application is generating a lot of errors for some reason.
Never tried it myself, but you probably can't disable this lock with
multiple threads running. You should take a look at the error log to
identify the cause of the errors. Then resolve the issue, whatever it may
be.
On 04/30/2015 06:52 PM, Bryan Call wrote:
This is for Apache Traffic Server and we have no knobs for turning on/off
FIPS. I am thinking about always disabling FIPS right now and that would
happen before we create the threads.
I was able to get rid of all the FIPS lock connection with the changes you
recommend (Big Thanks!). The big one now is type 1. I am printing out the
log every time the contention total is mod 1M. Are there any tricks I can
do for type 1 locks?
[Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock -
total contention: 400 waiting: 1 file: pmeth_lib.c line: 185 type: 10
[Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock -
total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
[Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock -
total contention: 400 waiting: 0 file: ex_data.c line: 304 type: 2
[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock -
total contention: 1200 waiting: 5 file: err.c line: 446 type: 1
[Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock -
total contention: 100 waiting: 0 file: rand_lib.c line: 212 type: 19
-Bryan
___
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
.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Trying to understand DTLS (as it applies to webrtc)
On 01/05/15 02:11, faraz khan wrote: Hi everyone, This is my first time posting to this list - so if theres a better place for this question please let me know. The problem I'm trying to fix applies to the Janus webrtc gateway (https://github.com/meetecho/janus-gateway) and my application which is using native C++ webrtc. What happens is that after hundreds of successful connections, sometimes the Janus server is unable to negotiate a DTLS handshake and after a key exchange the webrtc client replied with a DTLS Alert: Decrypt failed message. I'm attaching a wireshark trace of the issue happening and one for the correct negotiation. Can you confirm that the trace you attached for the correct negotiation also came from Janus? I spotted some odd things about the extensions in the ClientHello: It has the extended master secret extension. That extension is not supported by any released version of OpenSSL (we have it in the dev version of 1.1.0 - but that is unreleased). It correctly adds the ec_point_formats and elliptic_curves extensions. However it so happens that OpenSSL 1.0.1f has a bug in it (not in the latest version) which suppresses those extensions for DTLS (this is a significant enough bug in itself that it is worthwhile upgrading your OpenSSL) OpenSSL always adds extensions in the same order - and these extensions are in a different order. Due to the above it looks to me like the OpenSSL DTLS stack was not used to generate that ClientHello. The failed one *does* look like an OpenSSL generated ClientHello. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] PEM_read_bio_PrivateKey(..) or PEM_read_bio_RSAPrivateKey(..) both returns NULL
Hi, I have a privatekey file written using the call PEM_write_bio_RSAPrivateKey (...) The file write operation has been successful. However, when i am trying to read it via calls PEM_read_bio_PrivateKey(..) or PEM_read_bio_RSAPrivateKey(..) , it is always returning NULL. There is no encryption also done . It i unencrypted private key. Can someone help me to understand what might be wrong. And the same is while reading public key also Actually write operations are successful but read operations are not successful, what I am might be missing? Thanks Regards, Nayna Jain___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Trying to understand DTLS (as it applies to webrtc)
Matt, Thanks for taking the time to go through this. Unfortunately this error only happens when WebRTC is acting as the server in the dtls handshake and no logs (at all) seem to be printed but I think that's because openssl logging is done in a different way in native WebRTC which I'm not handling. I'll try increasing logs and / or printing openssl errors. The janus server gets the alert packet which I'm guessing is an error produced by the server in the transaction above. I'm assuming the problem is with the client reply that janus sent. Any idea what it could have sent wrong that WebRTC didn't like? Could it have encrypted the message with a wrong crypto or something or is this negotiation wholly handled by openssl? I'm trying to understand if janus is doing something wrong or is the dtls stuff completely handled by libssl - in which case this might be a dtls bug? I'm a newbie to openssl and dtls so dont mind the stupid questions. I however do know C and socket stuff so can get in to check with some guidance :) On Fri, May 1, 2015, 2:37 AM Matt Caswell m...@openssl.org wrote: On 01/05/15 02:11, faraz khan wrote: Hi everyone, This is my first time posting to this list - so if theres a better place for this question please let me know. The problem I'm trying to fix applies to the Janus webrtc gateway (https://github.com/meetecho/janus-gateway) and my application which is using native C++ webrtc. What happens is that after hundreds of successful connections, sometimes the Janus server is unable to negotiate a DTLS handshake and after a key exchange the webrtc client replied with a DTLS Alert: Decrypt failed message. I'm attaching a wireshark trace of the issue happening and one for the correct negotiation. The problem refuses to fix itself till Janus is restarted. Both installations are using Openssl. Janus is compiled with version 1.0.1f If someone can help explain how DTLS key exchange works and whats going wrong in the above trace it would be great! I'm completely at a loss as far as this is concerned! Thanks all! H. I can't see anything obviously wrong with the above traces. The handshake seems to proceed as normal and then fail near the end. A couple of things of note: * A client cert is being sent, but it has expired. I don't think this is the problem though because it is the same cert in the good trace and the bad trace. Validity Not Before: Feb 9 16:18:45 2007 GMT Not After : Feb 8 16:18:45 2009 GMT * A different ciphersuite is being negotiated between the good version and the bad version. Good is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, whilst Bad is TLS_RSA_WITH_AES_256_CBC_SHA. I'm not sure if that is significant, but I can't see why a server restart would make any difference if it were. Are there any server logs which might indicate why it is sending the alert? Looking at the code there are only a few places in the code which generate a decrypt error alert. It would probably help diagnose the problem if we could narrow down which of those places this is coming from. OpenSSL adds an error to its error queue for each of those places. The other point of note is that there have been quite a lot of DTLS related defect fixes in the OpenSSL code since 1.0.1f. An upgrade would be a really good idea. 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] Trying to understand DTLS (as it applies to webrtc)
On 01/05/15 16:51, faraz khan wrote: Matt, Thanks for taking the time to go through this. Unfortunately this error only happens when WebRTC is acting as the server in the dtls handshake and no logs (at all) seem to be printed but I think that's because openssl logging is done in a different way in native WebRTC which I'm not handling. I'll try increasing logs and / or printing openssl errors. The janus server gets the alert packet which I'm guessing is an error produced by the server in the transaction above. Yes. You can see the following exchanges in the traces: ClientServer ---- ClientHello ServerHello Certificate CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec [Finished (Encrypted)] -- Alert (Decrypt Error) If I understand your setup correctly (I'm not familiar with Janus or WebRTC), Janus is acting as the client here and WebRTC is the server, and both are using OpenSSL? I'm assuming the problem is with the client reply that janus sent. Any idea what it could have sent wrong that WebRTC didn't like? Could it have encrypted the message with a wrong crypto or something or is this negotiation wholly handled by openssl? I'm trying to understand if janus is doing something wrong or is the dtls stuff completely handled by libssl - in which case this might be a dtls bug? The server doesn't like something the Client sent in the last flight of messages, i.e. the Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec or Finished. It's unlikely to be the Certificate as, as far as I can tell, its the same Certificate in the good exchange versus the bad. So that means either the ClientKeyExchange, CertificateVerify or Finished messages (CCS is super simple so I don't think its that). Is WebRTC using 1.0.1 too (and if so which letter version)? Looking at the 1.0.1 code there are only a few places where a decrypt error can come from. Possible causes (in 1.0.1 code base): - digest check failed processing the Finished message - CRL signature failure processing the client Certificate - Bad RSA decrypt processing the CertificateVerify - Bad RSA signature processing the CertificateVerify There are a few other places that emit Decrypt Error alerts but none of them seem to apply here. Getting some additional logging might help us figure out which one of these is the cause. These are all quite low level issues though...deep in OpenSSL internals. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Trying to understand DTLS (as it applies to webrtc)
On 01/05/15 20:09, faraz khan wrote: Matt, Thanks again! To be precise webrtc is using boringssl (Google's fork of openssl). From the commits it seems VERY recent but I'm unable to figure out the last openssl merge-in. You think this could be the issue? Should I try both with boringSSL (its kinda hard to compile webrtc with openSSL now since after the move to boringSSL) Ahhh. BoringSSL. That means a slightly different list of potential causes (they forked OpenSSL 1.0.2, and have continued to make changes since then). I've just checked the latest dev version, and that means possible causes: - digest check failed processing the Finished message - CRL signature failure processing the client Certificate - Overly short RSA key - Bad RSA decrypt/signature processing the CertificateVerify To be honest I am more inclined to believe it is a problem on the client side rather than the WebRTC side. The fact that it goes away after you restart the client suggests to me that the client is getting itself into a strange state. Perhaps some kind of memory corruption (either through client application or openssl bug)? Anyway I'd suggest two things as next steps: - Try and figure out how to get more logging out of WebRTC to find out more specifically what it is complaining about - Upgrade your OpenSSL version to 1.0.1m Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Trying to understand DTLS (as it applies to webrtc)
Matt, Thanks again! To be precise webrtc is using boringssl (Google's fork of openssl). From the commits it seems VERY recent but I'm unable to figure out the last openssl merge-in. You think this could be the issue? Should I try both with boringSSL (its kinda hard to compile webrtc with openSSL now since after the move to boringSSL) On Fri, May 1, 2015 at 9:33 AM Matt Caswell m...@openssl.org wrote: On 01/05/15 16:51, faraz khan wrote: Matt, Thanks for taking the time to go through this. Unfortunately this error only happens when WebRTC is acting as the server in the dtls handshake and no logs (at all) seem to be printed but I think that's because openssl logging is done in a different way in native WebRTC which I'm not handling. I'll try increasing logs and / or printing openssl errors. The janus server gets the alert packet which I'm guessing is an error produced by the server in the transaction above. Yes. You can see the following exchanges in the traces: ClientServer ---- ClientHello ServerHello Certificate CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec [Finished (Encrypted)] -- Alert (Decrypt Error) If I understand your setup correctly (I'm not familiar with Janus or WebRTC), Janus is acting as the client here and WebRTC is the server, and both are using OpenSSL? I'm assuming the problem is with the client reply that janus sent. Any idea what it could have sent wrong that WebRTC didn't like? Could it have encrypted the message with a wrong crypto or something or is this negotiation wholly handled by openssl? I'm trying to understand if janus is doing something wrong or is the dtls stuff completely handled by libssl - in which case this might be a dtls bug? The server doesn't like something the Client sent in the last flight of messages, i.e. the Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec or Finished. It's unlikely to be the Certificate as, as far as I can tell, its the same Certificate in the good exchange versus the bad. So that means either the ClientKeyExchange, CertificateVerify or Finished messages (CCS is super simple so I don't think its that). Is WebRTC using 1.0.1 too (and if so which letter version)? Looking at the 1.0.1 code there are only a few places where a decrypt error can come from. Possible causes (in 1.0.1 code base): - digest check failed processing the Finished message - CRL signature failure processing the client Certificate - Bad RSA decrypt processing the CertificateVerify - Bad RSA signature processing the CertificateVerify There are a few other places that emit Decrypt Error alerts but none of them seem to apply here. Getting some additional logging might help us figure out which one of these is the cause. These are all quite low level issues though...deep in OpenSSL internals. 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] Error signing document
Great Dave this did the trick. Thanks, Mark Van: openssl-users [openssl-users-boun...@openssl.org] namens Dave Thompson [dthomp...@prinpay.com] Verzonden: vrijdag 1 mei 2015 6:59 Aan: openssl-users@openssl.org Onderwerp: Re: [openssl-users] Error signing document From: openssl-users On Behalf Of m.de.groot Sent: Thursday, April 30, 2015 14:46 I converted the pfx file to a pem file using the following command openssl pkcs12 -in CustKeyIcBD001.pfx -out CustKeyIcBD001.pem -nodes After this I trying to sign a file using this key with the following command openssl cms -sign -in TestfileIN.txt -out TestfileSign.tmp -outform DER - binary -nodetach -md SHA1 -signer CustKeyIcBD001.pem However I keep getting the message No signer certificate specified If you have accurately copied your command to the email, you are using a Windows-cp1252 dash character (hex code 96) not a hyphen (2D) for the -signer option. Use the classic traditional ASCII hyphen. ___ 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] Trying to understand DTLS (as it applies to webrtc)
On 01/05/15 02:11, faraz khan wrote: Hi everyone, This is my first time posting to this list - so if theres a better place for this question please let me know. The problem I'm trying to fix applies to the Janus webrtc gateway (https://github.com/meetecho/janus-gateway) and my application which is using native C++ webrtc. What happens is that after hundreds of successful connections, sometimes the Janus server is unable to negotiate a DTLS handshake and after a key exchange the webrtc client replied with a DTLS Alert: Decrypt failed message. I'm attaching a wireshark trace of the issue happening and one for the correct negotiation. The problem refuses to fix itself till Janus is restarted. Both installations are using Openssl. Janus is compiled with version 1.0.1f If someone can help explain how DTLS key exchange works and whats going wrong in the above trace it would be great! I'm completely at a loss as far as this is concerned! Thanks all! H. I can't see anything obviously wrong with the above traces. The handshake seems to proceed as normal and then fail near the end. A couple of things of note: * A client cert is being sent, but it has expired. I don't think this is the problem though because it is the same cert in the good trace and the bad trace. Validity Not Before: Feb 9 16:18:45 2007 GMT Not After : Feb 8 16:18:45 2009 GMT * A different ciphersuite is being negotiated between the good version and the bad version. Good is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, whilst Bad is TLS_RSA_WITH_AES_256_CBC_SHA. I'm not sure if that is significant, but I can't see why a server restart would make any difference if it were. Are there any server logs which might indicate why it is sending the alert? Looking at the code there are only a few places in the code which generate a decrypt error alert. It would probably help diagnose the problem if we could narrow down which of those places this is coming from. OpenSSL adds an error to its error queue for each of those places. The other point of note is that there have been quite a lot of DTLS related defect fixes in the OpenSSL code since 1.0.1f. An upgrade would be a really good idea. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Performance problems with OpenSSL and threading
So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in
the code? I was confused about that.
When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see
if there was an error not not. Maybe there is a more efficient handle this,
like looking at the shutdown flag?
0 The read operation was not successful. The reason may either be a
clean shutdown due to a close notify alert sent by the peer (in
which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
possible, that the peer simply shut down the underlying transport
and the shutdown is incomplete. Call SSL_get_error() with the
return value ret to find out, whether an error occurred or the
connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).
When we call SSL_accept we also call SSL_get_error() to see we need to read or
write. Is there a more efficient way to tell if we need to read or write?
If the underlying BIO is non-blocking, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept() to
continue the handshake, indicating the problem by the return value -1.
In this case a call to SSL_get_error() with the return value of
SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The calling process then must repeat the call after taking appropriate
action to satisfy the needs of SSL_accept(). The action depends on the
underlying BIO. When using a non-blocking socket, nothing is to be
done, but select() can be used to check for the required condition.
When using a buffering BIO, like a BIO pair, data must be written into
or retrieved out of the BIO before being able to continue.
Thank you...
-Bryan
On May 1, 2015, at 5:34 AM, John Foley fol...@cisco.com wrote:
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It
appears your application is generating a lot of errors for some reason.
Never tried it myself, but you probably can't disable this lock with multiple
threads running. You should take a look at the error log to identify the
cause of the errors. Then resolve the issue, whatever it may be.
On 04/30/2015 06:52 PM, Bryan Call wrote:
This is for Apache Traffic Server and we have no knobs for turning on/off
FIPS. I am thinking about always disabling FIPS right now and that would
happen before we create the threads.
I was able to get rid of all the FIPS lock connection with the changes you
recommend (Big Thanks!). The big one now is type 1. I am printing out the
log every time the contention total is mod 1M. Are there any tricks I can
do for type 1 locks?
[Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock -
total contention: 400 waiting: 1 file: pmeth_lib.c line: 185 type: 10
[Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock -
total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
[Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock -
total contention: 400 waiting: 0 file: ex_data.c line: 304 type: 2
[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock -
total contention: 1200 waiting: 5 file: err.c line: 446 type: 1
[Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock -
total contention: 100 waiting: 0 file: rand_lib.c line: 212 type: 19
-Bryan
___
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] Trying to understand DTLS (as it applies to webrtc)
On Fri, May 01, 2015 at 09:01:47PM +0100, Matt Caswell wrote: On 01/05/15 20:09, faraz khan wrote: Matt, Thanks again! To be precise webrtc is using boringssl (Google's fork of openssl). From the commits it seems VERY recent but I'm unable to figure out the last openssl merge-in. You think this could be the issue? Should I try both with boringSSL (its kinda hard to compile webrtc with openSSL now since after the move to boringSSL) Ahhh. BoringSSL. That means a slightly different list of potential causes (they forked OpenSSL 1.0.2, and have continued to make changes since then). I've just checked the latest dev version, and that means possible causes: - digest check failed processing the Finished message - CRL signature failure processing the client Certificate - Overly short RSA key - Bad RSA decrypt/signature processing the CertificateVerify To be honest I am more inclined to believe it is a problem on the client side rather than the WebRTC side. The fact that it goes away after you restart the client suggests to me that the client is getting itself into a strange state. Perhaps some kind of memory corruption (either through client application or openssl bug)? Anyway I'd suggest two things as next steps: - Try and figure out how to get more logging out of WebRTC to find out more specifically what it is complaining about - Upgrade your OpenSSL version to 1.0.1m He could also try to use something like valgrind to see if memory gets corrupted, or use build it using address sanitizer. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Performance problems with OpenSSL and threading
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.
It appears your application is generating a lot of errors for some
reason. Never tried it myself, but you probably can't disable this lock
with multiple threads running. You should take a look at the error log
to identify the cause of the errors. Then resolve the issue, whatever
it may be.
On 04/30/2015 06:52 PM, Bryan Call wrote:
This is for Apache Traffic Server and we have no knobs for turning
on/off FIPS. I am thinking about always disabling FIPS right now and
that would happen before we create the threads.
I was able to get rid of all the FIPS lock connection with the changes
you recommend (Big Thanks!). The big one now is type 1. I am
printing out the log every time the contention total is mod 1M. Are
there any tricks I can do for type 1 locks?
[Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for
lock - total contention: 400 waiting: 1 file: pmeth_lib.c line:
185 type: 10
[Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for
lock - total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
[Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for
lock - total contention: 400 waiting: 0 file: ex_data.c line: 304
type: 2
*[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for
lock - total contention: 1200 waiting: 5 file: err.c line: 446
type: 1*
[Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for
lock - total contention: 100 waiting: 0 file: rand_lib.c line: 212
type: 19
-Bryan
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Performance problems with OpenSSL and threading
The changes to SSL_locking_callback() look good. But the code you've
added to SSL_CTX_add_extra_chain_cert_file() doesn't accomplish much.
You're checking if FIPS is on or off, then setting the FIPS mode to the
current setting, which is a no-op.
On 04/30/2015 09:49 PM, Bryan Call wrote:
(plain text and removed most of the history)
John if you don’t mind reviewing my change to Apache Traffic Server. It
seems to be working very well. Thank you again!
https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blobdiff;f=iocore/net/SSLUtils.cc;h=0b732440636ab4e9eaedf237a5674bdc790c3e73;hp=2fae4820d7bab301340368e6be22445476d8d948;hb=d41e96f;hpb=ba1d6f7c9394c5efadb68cf9cf06f9b90f267b09
-Bryan
On Apr 30, 2015, at 3:52 PM, Bryan Call bc...@apache.org wrote:
This is for Apache Traffic Server and we have no knobs for turning on/off
FIPS. I am thinking about always disabling FIPS right now and that would
happen before we create the threads.
I was able to get rid of all the FIPS lock connection with the changes you
recommend (Big Thanks!). The big one now is type 1. I am printing out the
log every time the contention total is mod 1M. Are there any tricks I can
do for type 1 locks?
[Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock -
total contention: 400 waiting: 1 file: pmeth_lib.c line: 185 type: 10
[Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock -
total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
[Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock -
total contention: 400 waiting: 0 file: ex_data.c line: 304 type: 2
[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock -
total contention: 1200 waiting: 5 file: err.c line: 446 type: 1
[Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock -
total contention: 100 waiting: 0 file: rand_lib.c line: 212 type: 19
-Bryan
___
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] SHA256() to EVP_* ?
Even a small convenience is still a convenience. And eventually they add up. Thanks for the comments - it's appreciated. -- View this message in context: http://openssl.6102.n7.nabble.com/SHA256-to-EVP-tp57774p57826.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [resending from the correct email address; list moderator, if you see this first, just delete the one in the non-member queue] On 2/24/15 10:10 AM, Dr. Stephen Henson wrote: So the embedded content type will be enveloped data? If so first you can check that type using CMS_get0_eContentType(). Then you can use CMS_get0_content() to retrieve the embedded content as a pointer to an OCTET STRING pointer. You should check that content is not NULL and then retrieve the encoding of the content using ASN1_STRING_data and ASN1_STRING_length. Once you have those you can decode using d2i_CMS_ContentInfo(). ok, i'm not understanding how i supply the private key for decrypting the enveloped data in this scenario. thanks, richard -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQ33EAAoJEBg+LdNh/YEcvwAP/16TWRrGEPlVTSR9KGdezeSm 4ViStqMGbS2QHAmMHEZhypJMjuMEeeXJARXybH2ymCg8F6ATVRge5z4LGvSQheKu 5XU/sgw6T9rTuMcLuKiUnwqiIeFuz3IgDlBEwNOdS5DHXqWbfnbE6C5q/4d1mp7O IttTQlsmPNE61+jiyffK4UYTG5wnHac58l7OYVrnS08ViIeCYC9vhNV9iFaQqekB 04r9eEs0NKzbfMGaiAVyZqkCJlFvfpH55cgPqHD4xu+yUDb4zAvA0N7tmYiGSPOa nhCr9gwKKCVZvSsbZ45OUNpwrDIqFdKwgonKOfNOl28LeuMMXssrm2PM5yXvuQwR YrP/vSj+4zuWtLg1J+vOciKb3LL+WOeJtMhHu9UDdLkQ2T7uPEdkSUSNn83P6YNu DPFeW807omn3A3VgZhBbzd283/jEMkQOXZmrXOrPZ/vz95lFk4fLsDL6JtuMDryd 0aZila+Fm9NSm5AdMfC2Maf9wK2QFR/lbb7+CVi7nLWzY6nJjcHGrYvXn5NupaNF bZ78+FOgbEJ5poktU+e68Iz1RhEGtSPuc6z8n8CA7F8NdFybsBzy16V16bAoBSdO gLYWaDpWT6t2IRUkdNLwyBaMNuCMnkhl7MDjYIzZgmYWPD04yH46I9esehr99hrg 39ihWLRHKM/CZVspAh4/ =DS0I -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS questions
On Fri, May 01, 2015, Richard Welty wrote: On 2/24/15 10:10 AM, Dr. Stephen Henson wrote: So the embedded content type will be enveloped data? If so first you can check that type using CMS_get0_eContentType(). Then you can use CMS_get0_content() to retrieve the embedded content as a pointer to an OCTET STRING pointer. You should check that content is not NULL and then retrieve the encoding of the content using ASN1_STRING_data and ASN1_STRING_length. Once you have those you can decode using d2i_CMS_ContentInfo(). ok, i'm not understanding how i supply the private key for decrypting the enveloped data in this scenario. You get back a CMS_ContentInfo structure which you can then process using the appropriate CMS functions such as CMS_decrypt(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Performance problems with OpenSSL and threading
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It appears your application is generating a lot of errors for some reason. Never tried it myself, but you probably can't disable this lock with multiple threads running. You should take a look at the error log to identify the cause of the errors. Then resolve the issue, whatever it may be. I have a rewrite of the error-stack stuff that halves the number of locks. If you want to try it, drop me a line. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
