DoH: some options from user's transfer are not properly inherited

[3dyd]

Take a look at these lines from dohprobe:

curl/lib/doh.c

Lines 277 to 282 in 8063c32

	/* Inherit *some* SSL options from the user's transfer. This is a
	best-guess as to which options are needed for compatibility. #3661 */
	if(data->set.ssl.falsestart)
	ERROR_CHECK_SETOPT(CURLOPT_SSL_FALSESTART, 1L);
	if(data->set.ssl.primary.verifyhost)
	ERROR_CHECK_SETOPT(CURLOPT_SSL_VERIFYHOST, 2L);

If data->set.ssl.primary.verifyhost is set to zero, appropriate option in DoH handle stays untouched. But its default value is 2. I.e. currently you cannot disable certificate's name verification for DoH request.

Not sure if this is intended behavior. And if it is, at least the comment is a bit misleading.

Affected options (whose default value is not zero):

• CURLOPT_SSL_VERIFYHOST
• CURLOPT_PROXY_SSL_VERIFYHOST
• CURLOPT_SSL_VERIFYPEER
• CURLOPT_PROXY_SSL_VERIFYPEER
• + any used option whose default value would change in future.

Similar concern for the code constructions like the following one:

if(data->set.ssl.falsestart)
  ERROR_CHECK_SETOPT(CURLOPT_SSL_FALSESTART, 1L);

(Not sure though if this may generally happen in the library but) If option (falsestart in this case) would be expanded in further library versions (get more values than '0' or '1') then code like this will need to be revisited what is easy to overlook.

[jay]

Ref: 9e6af11

My fault, looks like that was my intention:

I did inherit insecure because I think that should still be in control of the user.

#4579 proposed fix

(Not sure though if this may generally happen in the library but) If option (falsestart in this case) would be expanded in further library versions (get more values than '0' or '1') then code like this will need to be revisited what is easy to overlook.

Yes, if those option values are expanded the code you cited should be amended. All the current internal members are bool, and they would have to be updated everywhere if they were changed from bool.

[bagder]

I think what's possibly more complicated is that CURLOPT_SSL_VERIFYHOST is for verifying the host curl connects to and it doesn't necessarily means that we should do the same thing for the host it connects to when resolving the host name using DoH...

[3dyd]

Isn't this concern relevant for all inherited options?

One of strong libcurl sides is reasonable defaults. In context of this topic it would be great to keep current approach as it is simple to use, better than noop, and (subjectively) more expected behavior. Then maybe add as alternative some CURLOPT_XXXFUNCTION to tune DoH handle if one would need grained control over it?

[jay]

I think what's possibly more complicated is that CURLOPT_SSL_VERIFYHOST is for verifying the host curl connects to and it doesn't necessarily means that we should do the same thing for the host it connects to when resolving the host name using DoH...

That was the intention though, rather than establish a separate set of DOH options inherit relevant options from the user's handle, and I think that's true of --insecure. This bug was just a mistake on my part.