Therefore, the only way to know that something is stored encrypted is to have your client (which may have a trusted code library) upload ciphertext and never give keys to the server. That's almost never how it works; but that's the only way to know that it's encrypted.

@SteffenUllrich I agree with you that it's best to wrap up the crypto. But what I am saying is that if you upload plaintext with a key in the http header inside of mTLS, or perform a get request with a key in the header; you actually have no idea if it's stored encrypted or not.

A good example of this is AWS encryption of S3 bucket files. You can specify a crypto key. If you don't supply the expected key, you get an error. But you have absolutely no idea how AWS actually stores the files. When you think about this, the first thing that comes to mind is that you never specified a block mode. If it was stored plaintext, you would not be able to tell. You need ciphertext and decrypting it yourself to know.

i really like the suggestion of: head -c32 /dev/urandom | base64

example of "entropy". roll a 16-sided dice to get 4 bits. whether it's encoded as binary in base64, or as ascii A-F, or as words mapped to bit combinations does not matter. if you can write it down, 64 rolls of a "16-sided dice" is 256 bits of entropy. i added such entropy as a parameter to supplement a terrible random number generator in MySQL before.

if there's a timestamp that correlates with when this is done to within a second, there could literally be no entropy at all. adding in insufficient randomness doesn't hurt in itself though. you need way more than a timestamp. you should at least add a long random phrase or dice rolls. entropy need not have weird chars; just randomness.

the DNS lookup is plaintext (convert www.xvideos.com to an IP address). other than that, the TLS connection is encrypted. There should be no way to see URLs... EXCEPT, your browser trusts a ton of certs. You literally trust the US government, Turkish Intel agencies, and their enemies. It's possible that you trusted a cert that was on its way to that site. Or this is a log FROM that site. TLS can't stop these scenarios. Or plugins collecting info, then leaking it...

i was on a project where we had to report a user-controllable divide-by-zero as a major security hole to the US government. users could craft packets that would cause a mod 0 operation, which causes divide by 0. the thing that got killed was an intrusion prevention system. so, you could turn it off with a crafty packet, just before you began an attack. of course this is a very strange and specific example.

He's making an obvious observation about end-to-end encryption, that almost everybody running servers in the cloud seems to have forgotten.

I don't understand the downvotes on this. TLS protects you from rogue middle-boxes leading to the cloud provider only. TLS is plaintext on both ends of it, and if one end is inside the cloud provider, then it's not open to "everyone", but it is surely readily compromised by the service provider. It is a development effort for the cloud provider to break your crypto, but governments have the procedure down. First, your server cert is on the server machine.

if it's over https, it's not as bad as passing in a password, or something that can also be used for other purposes.

from the original post: "on the same server as an application holding the credentials to said database in plain text." this unfortunately, is a very common scenario. i would not say "no protection", but it doesn't protect you from anybody you would worry about. it's common because people want to be able to do an unattended reboot.

this is the difference between protecting against incompetent snooping versus competent snooping. they can't simply run "strings" against the database files, but won't stop somebody that grabs the database and does a minimal amount of development to read all of it later.