>why would you care if the certificates are self-signed? You are arguing instead to not use encryption at all! Do you see how backward this is?
(I've chopped your quote a bit so that it applies to the internet in general rather than just a trusted network, which is what I think you're arguing for. Correct me if I'm wrong).
I do see how backward it is, but I don't think we have good enough solutions in place to protect against impersonated TLS. Users currently expect "safe and secure" from HTTPS, which is why there was a push to throw big scary warnings for non-authenticated TLS. Perhaps this is a UI problem, but until users are safely able to identify the difference between trusted connection and secure connection, I don't think we're ready for TLS everywhere without authentication.
If it is a problem that can be solved, it can be solved now.
I'm more concerned that my dad will have his banking session impersonated rather than his general browsing sessions snooped on after the fact. I would prefer that neither was possible, but I'm not aware of any good solution.
>Which implies encryption (on that connection) being not secure. Which is wrong.
No it is not wrong, even your confusingly worded sentence there is still fully correct.
Security (or encryption, or any other synonym you can come up with here) is made up of 3 (well technically 4) parts:
* confidentiality
* integrity
* authenticity
* (and technically non-repudiation, but that doesn't really apply here)
self-signed HTTPS certificates only provides 2 of the 3 (confidentiality and integrity) and it's that last one that is most important (authenticity), because without it you don't know who you are talking to. It could be your website, or it could be some asshole down the street pretending to be your website, you have literally no idea.
You say it's misleading, but it is you that is misreading and misunderstanding the concepts. Encryption without authentication is like encryption without a password. Utterly pointless.
> Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better.
StartTLS starts unencrypted then "upgrades" the connection to TLS if the client and server support it. This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless.
That's not to say TLS is perfect: having to trust an entire list of third-party CAs with their own incentives/pressures is a flawed model. But TLS is better than no TLS, so direct TLS is better than StartTLS.
That sounds strange, as I believe we're in disagreement. I believe the flexibility should exist, and choosing the transport medium of already encrypted data should be an option for the developer. This is completely unrelated to the security critical configuration of the TLS protocol, i.e. certs, keys, ciphersuites, etc.
>> The checksum is obviously transmitted out of line on a secure channel.
Then you have all the problems of setting up a second, secure channel. This would seem to increase complexity, not decrease it.
>> And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem.
Sure, if all your data is static this might help in terms of speed, you could drop some of the TLS overhead, though not all of it because you've still got to somehow verify a server signing key or your 'out of line' channel (which is probably going to have to be authenticated and integrity checked itself now.... TLS seems a good way to achieve this)
> I have looked into Syncthing and I found that their E2E setup is too daunting.
Are you referring to untrusted devices? That is different than e2e encryption. Synching is e2e encrypted by default. Synching relays are only used when a direct connection with a peer is not possible. When a relay is used the data is encrypted. The relay cannot read it.
> The security of a remote password manager will only be as secure as the transport encryption, this is true. But TLS is pretty solid these days, the risk of breaking it is much smaller than other risks involved here.
I would add for the sake of the conversation that any good password manager worth its salt (pun acknowledged) is using end to end encryption that isn’t reliant upon the promises of TLS.
(Authenticated) encryption on the client is key to any syncing password manager being able to fulfill expectations of privacy and security.
> I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest.
IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration.
>I would hardly call it secure. There have been too many failures with certificate authorities. The whole system is dependent on that weak point.
>Also do you keep track of the certificates issued to every website you visit? Then if you visit the website notice the certificate has changed. Do you check if it's a legitmate change ect.. If you don't keep track of certificates how do you even know you are not being MITM. You trust the certificate authority to handle that. However, certificate authorities clearly have signed or given out bad certificates.
still better than anyone being able to inject scripts when you're on an untrusted network. the requirement for a compromised CA drops the interception risk for most users to 0.
>Further, not everything requires an encrypted session. It just adds overhead for no good reason.
overhead of what? maybe a few hundred milliseconds on a 3g connection?
> Why is it reasonable to assume that? I don't think it is, at all. If their SSL certs are comprised, all bets are off.
I have no statistics to offer, but it does seem likely to me that TLS private keys gets compromised more frequently than software/package signing keys.
>> I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using.
There are multiple 'actual' issues here.
One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you.
The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this.
The third is giving away information about modules installed, which may be another risk. TLS will mitigate this.
You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.
> You can see where this is heading—a half-baked reimplementation of TLS client authentication with all the same usability nightmares.
Yeah, that's what I was thinking -- why would you do this instead of just using TLS client auth? TLS client auth is a usability nightmare -- but I'm not sure it's any _worse_ than what's in OP.
> The first part of that may be true, but the second part is definitely false. It is very hard to write your own secure anything-connected-to-a-network.
>We use an iboss content filter which can decrypt ssl and rencrypt on the fly.
Is it safe to assume this is some sort of trusted MITM proxy?
I think this is really taking it too far. We use Lightspeed and they block SSL traffic during the handshake based on the domain its destined for. No need to decrypt anything.
TLS has nothing to do with it. TLS is transport security, and would imply that the service provider can access your data.
I'm sorry to say this, but this is just word salad, including the "I'm not assuming it's compromised" bit.
> and entrust my most critical information with a 3rd party
The point is you don't need to do that, and can still sync over the Internet.
reply