12-05-2018, 10:13 AM
(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
