Shouldn't verify_SSL be true by default?

[miyagawa]

I think a false value for verify_SSL sounds like a bad default. It should be explicitly turned off or give errors/ warnings when failing to find certificates.

I think we document it clearly and with justifications for why this is the behavior here:

https://metacpan.org/pod/HTTP::Tiny#SSL-SUPPORT

[miyagawa]

Right, I read that and that's a little odd to me that "we turn it off because SSL adds a class in servers by discriminating non-paid certificates" is the default.

Maybe we can at least change that bit when https://letsencrypt.org/ is operational later this year?

I think the minimalist position we decided on is that we're not going to be responsible for the user's trust model.

By being in the user's face about it, we make them take an active position about their trust model. Sure, most users will flip on verify_SSL without thought, but then it's their own decision to expose themselves to hacked CA's issuing fraudulent certs. (amended to note that was an example of hacking, not incompetent CAs)

Maybe we should move that up in the docs. Blind trust is a form of security theater, so we don't want to default people into that.

[miyagawa]

I'm having a hard time understanding that non-verification of SSL is the good default because blind trust is a bad thing, because skipping SSL verification actually sounds more of a blind trust, from the user's point of view.

If that's the goal you're trying to achieve, requiring verify_SSL (either 0 or 1, there's no default) sounds like more correct thing to do, since from the look of the code HTTP::Tiny->new->get("https://example.com") you can't tell if the request is secure or not.

Note that i'm not actually suggesting that fix above, I still think enabling SSL verification by default (by looking at the host SSL certificate location or SSL_CERT_FILE environment), then warn if they're not found, is a better default.

It's even worse to default to "verify" but fallback with a warning. That's like BACKRONYM for mysql (albeit at the cert name level rather than the TLS level).

Either verification has to be on and enforced, or off.

If it helps with understanding, the difference is between these:

• "warning: we don't promise any trust"
• "just trust us and by extension trust whatever CAs we find"

We don't require people to use SSL. Users choose to provide an https URL. We don't require server name verification. Users choose to set verify_SSL. We don't require an explicit CA file. Users choose to set one.

Everything is opt-in.

I would feel differently if this was a browser, but it's just a very low-level protocol library. Anything user-facing that uses it can opt into whatever trust model it wants to offer to users.

[miyagawa]

OK then. I'll set verify_SSL in my own code.