4 ms·
Wait, so you're sending the key in the url? I thought urls weren't encrypted in HTTPS? Am I missing something?
by marcus_holmes 7y ago
Wait, so you're sending the key in the url?
I thought urls weren't encrypted in HTTPS? Am I missing something?
- denisu 7y agoUrls are encrypted.
- marcus_holmes 7y agowell, not the whole url, obviously, otherwise the router wouldn't know where to send the request
- dogma1138 7y agoThe entire URL is encrypted, the router doesn't need to know anything about the URL to route the packets. The only thing that can leak when you make an HTTPS connection is the DNS query.
- DaniloDias 7y agoYou are confusing layer 4 and later 7 concepts. Spend some time with wireshark running while you visit “google.com” in a web browser and you’ll get a better intuition on the topic.
- marcus_holmes 7y agothat makes sense, thanks
- inetknght 7y agoURLs are encrypted. Hostnames aren't encrypted in HTTPS, unless TLS SNI is encrypted. The problem with URLs is that a lot of products will log the URL to disk, and many operators forget or aren't aware they might need to have security plans around data in the logs.
- tialaramex 7y agoA worse and impossible to mitigate problem in other scenarios is that user agents will cheerfully "bookmark" or "favourite" a URL or just let you "share" it and it's often not obvious to the end user that this shares their current state which they probably don't want not just the thing they're looking at. Example: you try to share the forum help link but instead give the recipient your logged in account... This is the reason not to put authentication tokens into URLs for example. When the state users want to bookmark or share literally is the state that's encrypted anyway this mismatch isn't a threat. If I send you the URL for this drawing of a cat and then I'm astonished you can now see the drawing of the cat I've got real problems technology can't fix.
- marcus_holmes 7y agoyeah, this. Having the key in the url seems insanely insecure to me.
- henriquez 7y agoWhy? It makes it easy to share a sketch with someone else while still preventing the server from decrypting the data. Anything stored in a location hash (after the # symbol) does not get passed to the server. The threat model the author tried to work around is not the user dumbly compromising their own work. The author wants to prevent proprietary and PII data from being stored on their own server. End-to-end encryption significantly reduces the author's potential liability hosting something like this in case something goes wrong.
- inetknght 7y ago
- wstrm 7y agoAnything after the hash isn't sent to the server (it's mentioned in the article).
- nebster 7y agoThe article explained how the fragment part of the URL (everything after the #) isn't sent to the server. It's only client-side. So even if the URL isn't encrypted in HTTPS (it is though), it wouldn't matter.