Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Issue in TIdSSLIOHandlerSocketOpenSSL.OnStatusInfoEx
#1
Hello!
I found an issue by accident in TIdSSLIOHandlerSocketOpenSSL.OnStatusInfoEx for the need of writing an NSS-file to decrypt TLS-1.2-communication with Wireshark. It seems that the declaration of SSL3_STATE in IdSSLOpenSSLHeaders.pas shifts the memory content from the DLL one byte to left. When i shift the S3-Pointer via Dec(PByte(S3)) also one byte to left so it will work fine.
Please have a look for this thread in the german Delphi Praxis forum for sample codes and screen captures from IDE debug.
Greetz
Cody
Reply
#2
(12-04-2018, 10:05 AM)Codehunter Wrote: I found an issue by accident in TIdSSLIOHandlerSocketOpenSSL.OnStatusInfoEx for the need of writing an NSS-file to decrypt TLS-1.2-communication with Wireshark. It seems that the declaration of SSL3_STATE in IdSSLOpenSSLHeaders.pas shifts the memory content from the DLL one byte to left. When i shift the S3-Pointer via Dec(PByte(S3)) also one byte to left so it will work fine.

I have checked in a fix for IdSSLOpenSSLHeaders.pas. There was indeed a 1-off error in the declaration of the SSL3_STATE.write_mac_secret field, which is right above the server_random and client_random fields.

That being said, you really should not be accessing OpenSSL's record fields directly anymore. Use appropriate accessor functions from the OpenSSL API instead. In fact, once Indy is (eventually) updated to support OpenSSL 1.1+, direct access to record fields will no longer be possible at all, as ALL of OpenSSL's records were changed to opaque types in 1.1, so you MUST use accessor functions only. So, you may as well get in the habit of doing it now, because it is coming down the line in the future.

Reply
#3
(12-04-2018, 07:38 PM)rlebeau Wrote: I have checked in a fix for IdSSLOpenSSLHeaders.pas.  There was indeed a 1-off error in the declaration of the SSL3_STATE.write_mac_secret field, which is right above the server_random and client_random fields.

That being said, you really should not be accessing OpenSSL's record fields directly anymore.  Use appropriate accessor functions from the OpenSSL API instead.  In fact, once Indy is (eventually) updated to support OpenSSL 1.1+, direct access to record fields will no longer be possible at all, as ALL of OpenSSL's records were changed to opaque types in 1.1, so you MUST use accessor functions only.  So, you may as well get in the habit of doing it now, because it is coming down the line in the future.

Thank you for the quick fix! Prior i had read some discussions about Indy and TLS 1.3 including your statements about OpenSSL 1.1.1. I was thinking that these major changes in OpenSSL API would lead to heavy work on Indy for you and your coworkers. But i had not found a final decision from you, wheather Indy will support OpenSSL 1.1.1 in the future or not. Only we have a choice? The day will come and TLS 1.3 is state-of-the-art. Often, one of the big players (mostly Mozilla or Google) decide to drop the support of older encryption from their browsers. Not much later and many servers drops offering older encryption. Some of the REST servers for which i use Indy offers only TLS 1.2 anymore. When OpenSSL removes some crappy stuff from their API, i think this could be beneficial to Indy in the future.

When i should use OpenSSL directly, i need a re-design of definition how many hours a day have. 24 are not enough to me Wink
Reply
#4
(12-05-2018, 10:13 AM)Codehunter Wrote: Prior i had read some discussions about Indy and TLS 1.3 including your statements about OpenSSL 1.1.1. I was thinking that these major changes in OpenSSL API would lead to heavy work on Indy for you and your coworkers.

Yes, it will.

(12-05-2018, 10:13 AM)Codehunter Wrote: But i had not found a final decision from you, wheather Indy will support OpenSSL 1.1.1 in the future or not.

We are still discussing the particulars about it, and so there is no ETA at this time. It WILL happen, I just don't know WHEN.

(12-05-2018, 10:13 AM)Codehunter Wrote: The day will come and TLS 1.3 is state-of-the-art.

Yes, but not for a couple of years. It is still very new, not many sites are using it yet. TLS 1.1 and 1.2 will suffice for awhile, so there is still time.

(12-05-2018, 10:13 AM)Codehunter Wrote: Often, one of the big players (mostly Mozilla or Google) decide to drop the support of older encryption from their browsers.

Yes, but TLS 1.1 and 1.2 are not going to be dropped anytime soon (PCI didn't require migrating from TLS 1.0 to 1.1 until just earlier this year). The big players, and many websites, have only just recently started dropping TLS 1.0, and that has been around a long time (since 1999). For instance, Apple, Microsoft, Google, and Mozilla are not going to drop TLS 1.0 and 1.1 until 2020.

(12-05-2018, 10:13 AM)Codehunter Wrote: Some of the REST servers for which i use Indy offers only TLS 1.2 anymore.

Which is fine, since Indy supports TLS 1.2 today (it is just not enabled by default).

Reply
#5
(12-05-2018, 07:02 PM)rlebeau Wrote: Yes, but not for a couple of years.  It is still very new, not many sites are using it yet.  TLS 1.1 and 1.2 will suffice for awhile, so there is still time.

...

Which is fine, since Indy supports TLS 1.2 today (it is just not enabled by default).

I agree with you. The cause WHY i insist to support TLS 1.3 is a lesson from another front: Since Embarcadero has dropped using Indy in their REST client and switched to native-OS-connections, there are many problems on Windows 7 and Vista machines when connecting to TLS-1.2-only-servers. The support of 1.2 depends from some OS updates and registry patches. Much work for our field representatives at the customers side. Since we decide to drop using Delphi REST client and built our own one with Indy+OpenSSL, there are NO problems anymore with 1.2. In my mind's eye I saw the same problems with Indy and TLS 1.3 coming up.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)