Timeline for Is HTTPS required for local network server to server communication
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 14, 2021 at 8:21 | comment | added | Chibueze Opata | This answer like many others still overrates https even though appearing neutral. There're network environments that the implication of being insecure as carelessly mentioned here has by far over 100 times bigger implications. In such environment there's 100% no need for https, I know you're a security expert but say it, it won't hurt you. | |
| Mar 11, 2020 at 18:09 | comment | added | Criticizing Israel not allowed | @James_pic somehow I misread that as "1-bit RSA." | |
| Mar 10, 2020 at 18:24 | vote | accept | asinkxcoswt | ||
| Mar 10, 2020 at 14:36 | comment | added | James_pic | @BoogaRoo for server-to-server communication it doesn't matter whether Apple trusts your certs or not, only if your server does. If you're using libraries that allow you to configure them accordingly (many do), you can use SHA-1, 1024-bit RSA, no subject alt names, unreasonably long expiry periods, and all kinds of stuff that doesn't meet the baseline requirements and browsers and public CAs would baulk at. Which isn't to say that you should ignore good practice for no reason at all, but depending on your threat model, convenience may be a good enough reason. | |
| Mar 9, 2020 at 12:23 | comment | added | Voo | @James Sure, but I could name problems with that approach too.. remember when Chrome decided to require alternate subject names for its certificate validation? We had old internal certificates that didn't set those. Or about the fun of configuring node applications to use your internal root CA. And so on. My point isn't that these things are insurmountable, but that you shouldn't underestimate them. | |
| Mar 9, 2020 at 11:40 | comment | added | James_pic | @Voo For internal server-to-server authentication, there is no reason to use a public CA such as Let's Encrypt, and indeed it is likely better not to. You can use an internally managed CA for internal certificates, so there's no need to worry about renewal (you can set expiry to 100 years or whatever), you don't need to give the servers internet access, and there's no possibility that someone can trick a public CA into mis-issuing a certificate, since only certificates signed by your internal CA need to be valid. | |
| Mar 9, 2020 at 8:45 | comment | added | Voo | "Difficulty to maintain server certificates shouldn't be a problem nowadays, as this is common practice". You should tell the Microsoft Azure people that one. Or anyone who had outages due to the Let's Encrypt problem just last week, or.. I could go on. No really, the amount of outages due to problems with certificates in even the largest networks shows that this is not as trivial as people like to think in theory. And the consequences are severe. One really shouldn't underestimate that factor. | |
| Mar 8, 2020 at 13:48 | history | answered | Demento | CC BY-SA 4.0 |