Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What's your solution for SSL on internal servers?

news.ycombinator.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Ask HN: What's your solution for SSL on internal servers?

#71

Post by stephenr »

I'd already written a small (server focussed) tool to make use of certbot (or any ACME client really) certs a bit more automated (getting the right combination of certs/key in a file, converting to alternative formats, fetching the OCSP data, syncing across machines, restarting services after they're updated etc);

Last year I added in a 'create' mode where it sets up a self signed root CA, and issues certs using that. The other logic (convert, sync, combine) is obviously all the same still.

Re: Ask HN: What's your solution for SSL on internal servers?

#72

Post by savolai »

dboreham wrote: post #18
savolai wrote: post #7

Earlier quoted context omitted.

It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.

There is a long history to this. The original browser warnings were along the lines of your suggestion. Then it was discovered that regular users just clicked through the warning when an attacker MITM'ed their bank. There followed decades of making the warning ever more scary sounding and ever more difficult to bypass.

Where does responsibility lie here? Is there a mechanism for users to state trust towards their org's sysadmin instead of a global authority? If there isn't, what is the problem preventing this in the long history you mention?

Re: Ask HN: What's your solution for SSL on internal servers?

#73

Post by tqwhite »

ThermalCube wrote: post #19
savolai wrote: post #7

Earlier quoted context omitted.

It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.

(Untested idea) I'd suggest creating your own Root CA with an expire-date far in the future. Install it's public key as a trusted certificate and all derived certificates should not prompt any issues anymore

I did this on my workstation. I used it for a short while. Then I realized that I was actually putting a thing into the world that circumvents the entire security infrastructure of the world. Then I needed to do it for a server. Local only. Never production.

Then I thought, WTF am I doing?. I realized that I was making computers that would circumvent the world's security apparatus. Of course it won't hurt if I make no errors of practice or judgement but, am I really smart enough to handle highly radioactive material.

I ripped it all out. It makes me shudder thinking about it.

Re: Ask HN: What's your solution for SSL on internal servers?

#74

Post by BrandoElFollito »

ninkendo wrote: post #30
tyingq wrote: post #14

Earlier quoted context omitted.

It can be tricky to get self-signed certificates put into all the various places where they need to be. OS level certificate stores, browsers, mobile devices, curl, python/requests, VPN clients, etc. There's always some weird exception case.

Yeah, I think OP probably mostly does web development through the browser, where there’s just one trust store to worry about. As soon as you need some automation involving backend services or even just curl and some scripts, this gets tougher. (And please please don’t use `curl -k` to disable checks… if such scripts accidentally make their way to production, you may as well not use TLS at all.)

About the -k: why?

A certificate has two main functions: identity of the server and encryption. Not checking the chain leaves you with encryption, which is likely what your need.

A self-signed certificate is as good as any other when it comes to encryption.

Re: Ask HN: What's your solution for SSL on internal servers?

#76

Post by dlangille »

throw0101a wrote: post #65

DNS alias mode: * https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se... You want the name "internal.example.com". In your external DNS you create a CNAME from "_acme-challenge.internal.example.com" and point it to (e.g.) "internal.example. net " or "internal. dns-auth .example.com"…

I approve this post. /s

Re: Ask HN: What's your solution for SSL on internal servers?

#77

Post by ninkendo »

BrandoElFollito wrote: post #74
ninkendo wrote: post #30

Earlier quoted context omitted.

Yeah, I think OP probably mostly does web development through the browser, where there’s just one trust store to worry about. As soon as you need some automation involving backend services or even just curl and some scripts, this gets tougher. (And please please don’t use `curl -k` to disable checks… if such scripts accidentally make their way to production, you may as well not use TLS at all.)

About the -k: why? A certificate has two main functions: identity of the server and encryption. Not checking the chain leaves you with encryption, which is likely what your need. A self-signed certificate is as good as any other when it comes to encryption.

If you're in a situation where encryption matters to you, you're in a situation where the identity of the remote end ought to matter to you as well. If someone's able to snoop the traffic between you and the remote end, it's dangerous to assume they won't also be able to MITM you.

Re: Ask HN: What's your solution for SSL on internal servers?

#78

Post by BrandoElFollito »

ninkendo wrote: post #77
BrandoElFollito wrote: post #74

Earlier quoted context omitted.

About the -k: why? A certificate has two main functions: identity of the server and encryption. Not checking the chain leaves you with encryption, which is likely what your need. A self-signed certificate is as good as any other when it comes to encryption.

If you're in a situation where encryption matters to you, you're in a situation where the identity of the remote end ought to matter to you as well. If someone's able to snoop the traffic between you and the remote end, it's dangerous to assume they won't also be able to MITM you.

A self-signed certificate provides an identity the same way as a CA-signed one. The only difference is that it is in a CA chain.

You may trust the CA enough to not check further, but if you want to make sure that the endpoint you are talking with is the one you expect, you should check the identity of the certificate on the server. And it is the same for a self-signed certificate as from a CA-issued one.

Re: Ask HN: What's your solution for SSL on internal servers?

#79

Post by ninkendo »

BrandoElFollito wrote: post #78
ninkendo wrote: post #77

Earlier quoted context omitted.

If you're in a situation where encryption matters to you, you're in a situation where the identity of the remote end ought to matter to you as well. If someone's able to snoop the traffic between you and the remote end, it's dangerous to assume they won't also be able to MITM you.

A self-signed certificate provides an identity the same way as a CA-signed one. The only difference is that it is in a CA chain. You may trust the CA enough to not check further, but if you want to make sure that the endpoint you are talking with is the one you expect, you should check the identity of the certificate on the server. And it is the same for a self-signed certificate as from a CA-issued one.

`curl -k` doesn't do any of that. It just connects via TLS and does no checking whatsoever on the remote server's identity.

And what you're saying about CA certs has no resemblance to reality. People don't look at certs by matching their public keys exactly to what they expect... they trust certificate authorities to make that determination for them. But again, `curl -k` does neither so I don't think your point applies regardless.

Post reply on HN