Skip to content

Commit

Permalink
TODO: CURL_REFUSE_CLEARTEXT
Browse files Browse the repository at this point in the history 
An idea that popped up in discussions on twitter.
  • Loading branch information
@bagder
bagder committed Jan 25, 2018
1 parent 02b7280 commit fd9f207
Showing 1 changed file with 10 additions and 0 deletions.
10 changes: 10 additions & 0 deletions docs/TODO
View file
Expand Up @@ -40,6 +40,7 @@
1.23 Offer API to flush the connection pool
1.24 TCP Fast Open for windows
1.25 Expose tried IP addresses that failed
1.26 CURL_REFUSE_CLEARTEXT

2. libcurl - multi interface
2.1 More non-blocking
Expand Down Expand Up @@ -393,6 +394,15 @@

https://github.com/curl/curl/issues/2126

1.26 CURL_REFUSE_CLEARTEXT

An environment variable that when set will make libcurl refuse to use any
cleartext network protocol. That's all non-encrypted ones (FTP, HTTP, Gopher,
etc). By adding the check to libcurl and not just curl, this environment
variable can then help users to block all libcurl-using programs from
accessing the network using unsafe protocols.


2. libcurl - multi interface

2.1 More non-blocking
Expand Down

14 comments on commit fd9f207

@vszakats
Copy link
Member

@vszakats vszakats commented on fd9f207 Jan 25, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bagder Would that also block HTTPS without certificate/host verification? (which isn't cleartext per se, yet still may be in line with the intent of this new setting.)

@bagder
Copy link
Member Author

@bagder bagder commented on fd9f207 Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say that is up for debate... maybe we could have the variable set different levels?

@vszakats
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good to me!

@monnerat
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a quick brain storming:

  • What about non-TLS protocols with STARTTLS? if we want to allow them, we have to defer error detection.
  • If we support them, how about FTP that can have either control/data connections encrypted or not ?
  • In any case, I think we might reject plain authentication if attempting to transmit it on a non-encrypted connection.

@vszakats
Copy link
Member

@vszakats vszakats commented on fd9f207 Jan 25, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO:

  • Non-TLS STARTTLS is similar to a HTTP to HTTPS redirect. I'd put this in the same "category" as disabled cert/host verification (i.e. their encryption can be exploited/disabled using similar techniques.)
  • Speaking of this setting I assumed that any non-encrypted connection would be rejected, regardless of the form (or presence) of authentication. But, this is also something that can be made fine-tunable.

@monnerat
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might also be a good idea to have it both as an environment variable and as a CURLOPT: some systems allow setenv() to update the environment inherited by future children, but not for the current process. In this case, the process itself cannot enforce this protection for its own calls without something like a CURLOPT (I know: CURLOPT_* are for a single handle, but there currently exists no curl_global_setopt())

@bagder
Copy link
Member Author

@bagder bagder commented on fd9f207 Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that could indeed be considered. Programs do have CURLOPT_PROTOCOLS though as an option already, which isn't exactly the same as we're discussing here but can be used similarly.

@monnerat
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Speaking of this setting I assumed that any non-encrypted connection would be rejected, regardless of the form (or presence) of authentication. But, this is also something that can be made fine-tunable.

I just looked through the code and it seems to be ok since AFAICS, authentication is always performed after STARTTLS.

@jay
Copy link
Member

@jay jay commented on fd9f207 Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why this is necessary, isn't protocol restriction enough? Where is the twitter thread I can't find it

@vszakats
Copy link
Member

@vszakats vszakats commented on fd9f207 Jan 25, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the original (envvar) proposal my understanding is that it's a way to override insecure app configuration/code by users (who have the power to control envvars, e.g. on desktops/servers). Meaning, an existing app decided it's fine to use HTTP or not to verify the certificate for HTTPS, but in certain use-cases it's useful to override such decision and say that such uses are not accepted.

@bagder
Copy link
Member Author

@bagder bagder commented on fd9f207 Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. This would allow a user to restrict what curl/libcurl is allowed to do even if the application otherwise is allowed to perform those insecure transfers.

@jay
Copy link
Member

@jay jay commented on fd9f207 Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a libcurl rc. I would rather leave it to app developers, they have to know that their program is going to work or not.

@bagder
Copy link
Member Author

@bagder bagder commented on fd9f207 Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then you wouldn't set this variable. With the variable set, you can for example prevent scripts that use curl from using insecure protocols or you can set it in your shell to avoid things like "curl -O http://example.com/installer-bin" to work because you want that local policy. And the same then goes for programs using libcurl. With such a variable a user can insist on a higher bar, even if the makers of the tool doesn't.

@jay
Copy link
Member

@jay jay commented on fd9f207 Jan 25, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I understand (now). I just disagree.

Please sign in to comment.