Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 9/29/2015 12:13 PM, Michael König wrote:

Hi everyone,

I got into a situation where i want to check what protocol version and cipher
was used for an SSL connection. (HTTPS)

I found CURLINFO_TLS_SESSION and it looked like it might give me access to the
information i need, but it does not. When using the OpenSSL backend
CURLINFO_TLS_SESSION returns the SSL_CTX. While the CTX contains information
that affected the creation of the SSL session. It does not contain any
information about the established connection. It contains the list of
acceptable ciphers, but not the information what cipher or protocol version was
actually used.

To probe that information from OpenSSL you need a pointer to the SSL object,
which holds the SSL_CTX and not the other way around.

Was there a reason for not returning the SSL object, or was it an oversight?
Changing the behaviour now feels like a really bad idea, due to the code
breaking potential. Is there any alternative? I did not check the other
backends as to how consistent the nature of the returned value is. I am only
somewhat familiar with CURLSSLBACKEND_SCHANNEL and could check that.



I've added CURLINFO_TLS_SSL_PTR [1][2] which should do what you want. 
The option name is subject to change. Barring anything unforeseen it 
will be in the next version of curl, 7.48.0.



[1]: https://curl.haxx.se/libcurl/c/CURLINFO_TLS_SSL_PTR.html
[2]: https://github.com/curl/curl/commit/332414a

---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Rich Gray]

Ray Satiro via curl-library wrote:

On 10/7/2015 9:10 AM, Daniel Stenberg wrote:

On Wed, 7 Oct 2015, Rich Gray wrote:


For what it's worth, CURLINFO_TLS_SSL_PTR seems more meaningful to me
than CURLINFO_TLS_SESSION_V2.  For maximum clarity, maybe
CURLINFO_TLS_CTX_PTR could be added as an alias for CURLINFO_TLS_SESSION
and the later "depreciated".


I'm with Rich here.

We need to consider the long term and "v2" will not age well so ten years
down the line this will leave people wondering about the v1. I prefer a
clear name that can stand on its own, which makes CURLINFO_TLS_SSL_PTR
better in my eyes.



Reviewing this thread we seem to be about evenly split here.
CURLINFO_TLS_SESSION_V2 I prefer because it's basically the same as
CURLINFO_TLS_SESSION but with the fix for OpenSSL. CURLINFO_TLS_SSL_PTR also
has the fix but is less appealing to me because it only returns the pointer
and not a CURLSSLBACKEND define indicating the SSL backend. We could take
the CURLINFO_TLS_SESSION_V2 and rename it CURLINFO_TLS_SSL_PTR and do some
minor doc work, but then it's not directly returning an SSL pointer.


FYI, I have no experience with the TLS components of libcurl.  I was just 
commenting that _V2 left me cold.  Perhaps there is yet a more descriptive 
name than CURLINFO_TLS_SSL_PTR.   CURLINFO_TLS_OBJECT??  I don't know.  Or 
use _V2 or CURLINFO_TLS_SESSIONX or something.  I defer to those who 
actually know about this stuff - what it means and what makes sense.


Cheers!
Rich
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 10/7/2015 9:10 AM, Daniel Stenberg wrote:

On Wed, 7 Oct 2015, Rich Gray wrote:

For what it's worth, CURLINFO_TLS_SSL_PTR seems more meaningful to me 
than CURLINFO_TLS_SESSION_V2.  For maximum clarity, maybe 
CURLINFO_TLS_CTX_PTR could be added as an alias for 
CURLINFO_TLS_SESSION and the later "depreciated".


I'm with Rich here.

We need to consider the long term and "v2" will not age well so ten 
years down the line this will leave people wondering about the v1. I 
prefer a clear name that can stand on its own, which makes 
CURLINFO_TLS_SSL_PTR better in my eyes.




Reviewing this thread we seem to be about evenly split here. 
CURLINFO_TLS_SESSION_V2 I prefer because it's basically the same as 
CURLINFO_TLS_SESSION but with the fix for OpenSSL. CURLINFO_TLS_SSL_PTR 
also has the fix but is less appealing to me because it only returns the 
pointer and not a CURLSSLBACKEND define indicating the SSL backend. We 
could take the CURLINFO_TLS_SESSION_V2 and rename it 
CURLINFO_TLS_SSL_PTR and do some minor doc work, but then it's not 
directly returning an SSL pointer.


The feature window I assume will be closing next week or soon after and 
I think it would be good if we could all agree on something to land this 
before it closes since the OpenSSL SSL pointer isn't exposed currently. 
Also as I mentioned in some other post I'm unclear about the right 
pointer for Apple's SecureTransport. I recall my read of their docs was 
their CTX is unique and basically their version of an SSL type pointer, 
so that's what I used but I'm not sure.


Anyone else want to take a look?

https://github.com/jay/curl/compare/master...jay:curlinfo_tls_ssl_ptr?expand=1
https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Rich Gray]

Ray Satiro via curl-library wrote:

I plan to put in the CURLINFO_TLS_SESSION_V2 implementation (credit to
Michael Kaufmann for suggesting that) instead of the
CURLINFO_TLS_SSL_PTR.


For what it's worth, CURLINFO_TLS_SSL_PTR seems more meaningful to me than 
CURLINFO_TLS_SESSION_V2.  For maximum clarity, maybe CURLINFO_TLS_CTX_PTR 
could be added as an alias for CURLINFO_TLS_SESSION and the later "depreciated".


Rich

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Daniel Stenberg]

On Wed, 7 Oct 2015, Rich Gray wrote:

For what it's worth, CURLINFO_TLS_SSL_PTR seems more meaningful to me than 
CURLINFO_TLS_SESSION_V2.  For maximum clarity, maybe CURLINFO_TLS_CTX_PTR 
could be added as an alias for CURLINFO_TLS_SESSION and the later 
"depreciated".


I'm with Rich here.

We need to consider the long term and "v2" will not age well so ten years down 
the line this will leave people wondering about the v1. I prefer a clear name 
that can stand on its own, which makes CURLINFO_TLS_SSL_PTR better in my eyes.


--

 / daniel.haxx.se
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 10/6/2015 6:21 AM, Frank Meier wrote:

Hi
Here is another idea, piggyback on CURLINFO_TLS_SESSION instead. 
CURLINFO_TLS_SESSION_V2 returns OpenSSL SSL * but is otherwise the 
same as CURLINFO_TLS_SESSION:


https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1 


+1

I'd really like seeing this patch being merged, since I also need to 
access the SSL* struct sometimes.


You'll have to wait a little bit. The feature window is closed now and 
though this is more a fix it introduces a new symbol. Later this month I 
can put it in and if nothing breaks it would go out in the December 
release. I plan to put in the CURLINFO_TLS_SESSION_V2 implementation 
(credit to Michael Kaufmann for suggesting that) instead of the 
CURLINFO_TLS_SSL_PTR.


---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Frank Meier]

Hi
Here is another idea, piggyback on CURLINFO_TLS_SESSION instead. 
CURLINFO_TLS_SESSION_V2 returns OpenSSL SSL * but is otherwise the 
same as CURLINFO_TLS_SESSION:


https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1 


+1

I'd really like seeing this patch being merged, since I also need to 
access the SSL* struct sometimes.


cheers, Frank


---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Michael König]

> Ray Satiro via curl-library  hat am 2. Oktober 2015
> um 20:34 geschrieben:
> 
> 
> On 10/2/2015 3:39 AM, Michael König wrote:
> >> Ray Satiro via curl-library  hat am 1. Oktober
> >> 2015
> >> um 21:03 geschrieben:
> >>
> >> Here is another idea, piggyback on CURLINFO_TLS_SESSION instead.
> >> CURLINFO_TLS_SESSION_V2 returns OpenSSL SSL * but is otherwise the same
> >> as CURLINFO_TLS_SESSION:
> >>
> >> https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1
> >>
> > If it was intended to eventually deprecate the current CURLINFO_TLS_SESSION
> > and replace it with the V2 version this would make sense. If that will not
> > be the case i think going with the maximum distance to CURLINFO_TLS_SESSION,
> > regarding the returned values, while doing what we want is the way to go. To
> > justify the existance of the new enum.
> 
> I'm not sure what you mean by "going the maximum distance". If you mean 
> change the structure to be more "full" so that V2 returns both the 
> SSL_CTX and SSL I think that's unnecessary because you can get the 
> SSL_CTX from the SSL. It appears this was just an oversight that SSL_CTX 
> instead of SSL is returned for OpenSSL in V1.
Maximum distance as in: Put in as much new value for users as possible, while
staying
in scope of the topic.
I was not too fond of CURLINFO_TLS_SESSION_V2 just fixing this one thing, maybe
more
could be done with it and in that case it would warrant a different name.

Since then i revised my opinion. CURLINFO_TLS_SESSION_V2 makes it pretty clear
it is
a bugfix. It was said before it is pretty much the only way to go to maintain
backward
compatibility.

The most important thing is that something is done about the SSL object really.

Sorry for the longish delay. Was ill part of last week and through the weekend.

Greetings,
  Michael

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 10/2/2015 3:39 AM, Michael König wrote:

Ray Satiro via curl-library  hat am 1. Oktober 2015
um 21:03 geschrieben:

Here is another idea, piggyback on CURLINFO_TLS_SESSION instead.
CURLINFO_TLS_SESSION_V2 returns OpenSSL SSL * but is otherwise the same
as CURLINFO_TLS_SESSION:

https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1


If it was intended to eventually deprecate the current CURLINFO_TLS_SESSION
and replace it with the V2 version this would make sense. If that will not
be the case i think going with the maximum distance to CURLINFO_TLS_SESSION,
regarding the returned values, while doing what we want is the way to go. To
justify the existance of the new enum.


I'm not sure what you mean by "going the maximum distance". If you mean 
change the structure to be more "full" so that V2 returns both the 
SSL_CTX and SSL I think that's unnecessary because you can get the 
SSL_CTX from the SSL. It appears this was just an oversight that SSL_CTX 
instead of SSL is returned for OpenSSL in V1.


---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Michael König]

> Ray Satiro via curl-library  hat am 1. Oktober 2015
> um 21:03 geschrieben:
> 
> Here is another idea, piggyback on CURLINFO_TLS_SESSION instead. 
> CURLINFO_TLS_SESSION_V2 returns OpenSSL SSL * but is otherwise the same 
> as CURLINFO_TLS_SESSION:
> 
> https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1
> 
If it was intended to eventually deprecate the current CURLINFO_TLS_SESSION
and replace it with the V2 version this would make sense. If that will not
be the case i think going with the maximum distance to CURLINFO_TLS_SESSION,
regarding the returned values, while doing what we want is the way to go. To
justify the existance of the new enum.
> ---
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette:  http://curl.haxx.se/mail/etiquette.html

Greetings,
  Michael
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 9/30/2015 8:15 PM, Ray Satiro wrote:
I started a draft [2] of CURLINFO_TLS_SSL_PTR to get the active SSL 
object for all SSL backends. In the case of DarwinSSL and WinSSL it 
appears the CTX is the SSL object, please correct me if this is wrong. 
Just written not built, I could use some feedback.



[1]: http://curl.haxx.se/mail/lib-2015-04/0154.html
[2]: 
https://github.com/jay/curl/compare/master...jay:curlinfo_tls_ssl_ptr?expand=1


Here is another idea, piggyback on CURLINFO_TLS_SESSION instead. 
CURLINFO_TLS_SESSION_V2 returns OpenSSL SSL * but is otherwise the same 
as CURLINFO_TLS_SESSION:


https://github.com/jay/curl/compare/master...jay:curlinfo_tls_session_v2?expand=1

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 9/29/2015 12:13 PM, Michael König wrote:

Hi everyone,

I got into a situation where i want to check what protocol version and cipher
was used for an SSL connection. (HTTPS)

I found CURLINFO_TLS_SESSION and it looked like it might give me access to the
information i need, but it does not. When using the OpenSSL backend
CURLINFO_TLS_SESSION returns the SSL_CTX. While the CTX contains information
that affected the creation of the SSL session. It does not contain any
information about the established connection. It contains the list of
acceptable ciphers, but not the information what cipher or protocol version was
actually used.

To probe that information from OpenSSL you need a pointer to the SSL object,
which holds the SSL_CTX and not the other way around.

Was there a reason for not returning the SSL object, or was it an oversight?
Changing the behaviour now feels like a really bad idea, due to the code
breaking potential. Is there any alternative? I did not check the other
backends as to how consistent the nature of the returned value is. I am only
somewhat familiar with CURLSSLBACKEND_SCHANNEL and could check that.


You can try using SSL_CTX_set_info_callback [1] to work with the SSL 
handle when the handshake is complete. I made an example [2] that shows 
how to read the version and cipher from the SSL handle. It doesn't take 
into account renegotiation. A bigger problem is afaict there is no user 
pointer to pass to OpenSSL for the curl handle so in the example there's 
no logic to tell which curl handle the SSL handle is associated with. 
There's probably a way around that without all sorts of trickery but I 
can't think of it at the moment.


I don't know why the SSL object isn't exposed. It's been proposed 
before, I don't remember what happened.


[1]: 
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_info_callback.html

[2]: https://gist.github.com/jay/982b70e50bdd8a86415c

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Michael Kaufmann]

Should we consider providing another pointer for the OpenSSL backend? 
Sure, I'm open for discussions and solutions!


Yes, please consider this. I propose to add a new CURLINFO constant, 
because the existing API must not be changed (backwards compatibility). 
We could call it CURLINFO_TLS_SESSION_EXTENDED or 
CURLINFO_TLS_SESSION_V2. It should work the same way as 
CURLINFO_TLS_SESSION, but with SSL* instead of SSL_CTX* for OpenSSL.


At first glance, this may look like a hack, but actually it is a clean, 
backwards compatible solution for a real problem.


Regards,
Michael
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Rich Gray]

Michael Kaufmann wrote:



Should we consider providing another pointer for the OpenSSL backend?
Sure, I'm open for discussions and solutions!


Yes, please consider this. I propose to add a new CURLINFO constant,
because the existing API must not be changed (backwards compatibility).
We could call it CURLINFO_TLS_SESSION_EXTENDED or
CURLINFO_TLS_SESSION_V2. It should work the same way as
CURLINFO_TLS_SESSION, but with SSL* instead of SSL_CTX* for OpenSSL.



If I've been following along correctly, SSL_CTX* is a subset of SSL*, so how 
about CURLINFO_TLS_SESSION_FULL ?


- Rich




---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Daniel Stenberg]

On Wed, 30 Sep 2015, Ray Satiro via curl-library wrote:

I don't know why the SSL object isn't exposed. It's been proposed before, I 
don't remember what happened.


(Not that I think it really matters WHY we did things the way we did in the 
past but the question should rather be what do we do now to make it better 
going forward, but I'll still bite and elaborate.)


It has a plain and simple explanation (and this goes pretty much for why _any_ 
feature in libcurl works the way it does): when we introduced this feature a 
patch was provided and discussed and then eventually we ended up merging that 
code with the provided functionality.


Nobody at the time objected or said we provided the wrong pointer or that we 
should provide another pointer too. So we did what was suggested. To me 
personally it also made some sort of sense since it is the same pointer we 
already provide in the SSL callback.


This is how everything is done in our project: we bring the idea, patch, bug 
fix, feature or crazy thought here to the list and everyone and anyone who 
thinks anything about it gets to state their opinion and then we try to steer 
in some direction based on what the discussion gave. And then we iterate over 
things so we can ALWAYS bring back a subject for another round.


Should we consider providing another pointer for the OpenSSL backend? Sure, 
I'm open for discussions and solutions!


--

 / daniel.haxx.se
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Ray Satiro via curl-library]

On 9/30/2015 6:32 AM, Daniel Stenberg wrote:

On Wed, 30 Sep 2015, Ray Satiro via curl-library wrote:

I don't know why the SSL object isn't exposed. It's been proposed 
before, I don't remember what happened.


(Not that I think it really matters WHY we did things the way we did 
in the past but the question should rather be what do we do now to 
make it better going forward, but I'll still bite and elaborate.)


It has a plain and simple explanation (and this goes pretty much for 
why _any_ feature in libcurl works the way it does): when we 
introduced this feature a patch was provided and discussed and then 
eventually we ended up merging that code with the provided functionality.


Nobody at the time objected or said we provided the wrong pointer or 
that we should provide another pointer too. So we did what was 
suggested. To me personally it also made some sort of sense since it 
is the same pointer we already provide in the SSL callback.


I wasn't baiting you :) I disagree. Maybe there was a really good reason 
at the time why it shouldn't be exposed. I couldn't find any. I used my 
awesome search powers to discover we talked about it earlier this year 
[1] but it didn't go anywhere.


I started a draft [2] of CURLINFO_TLS_SSL_PTR to get the active SSL 
object for all SSL backends. In the case of DarwinSSL and WinSSL it 
appears the CTX is the SSL object, please correct me if this is wrong. 
Just written not built, I could use some feedback.



[1]: http://curl.haxx.se/mail/lib-2015-04/0154.html
[2]: 
https://github.com/jay/curl/compare/master...jay:curlinfo_tls_ssl_ptr?expand=1


---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

CURLINFO_TLS_SESSION with OPENSSL returns SSL_CTX instead of SSL

[Michael König]

Hi everyone,

I got into a situation where i want to check what protocol version and cipher
was used for an SSL connection. (HTTPS)

I found CURLINFO_TLS_SESSION and it looked like it might give me access to the
information i need, but it does not. When using the OpenSSL backend
CURLINFO_TLS_SESSION returns the SSL_CTX. While the CTX contains information
that affected the creation of the SSL session. It does not contain any
information about the established connection. It contains the list of
acceptable ciphers, but not the information what cipher or protocol version was
actually used.

To probe that information from OpenSSL you need a pointer to the SSL object,
which holds the SSL_CTX and not the other way around. 

Was there a reason for not returning the SSL object, or was it an oversight?
Changing the behaviour now feels like a really bad idea, due to the code
breaking potential. Is there any alternative? I did not check the other
backends as to how consistent the nature of the returned value is. I am only
somewhat familiar with CURLSSLBACKEND_SCHANNEL and could check that.

Greetings
  Michael
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html