5 ms·

So you'd prefer not to have any crypto at all? Because 99% of people are going to use their browsers anyways. Btw for example https://blockchain.info/wallet/#/

So you'd prefer not to have any crypto at all? Because 99% of people are going to use their browsers anyways. Btw for example https://blockchain.info/wallet/#/ https://blockchain.info/wallet/#/ (in-browser bitcoin wallet) I think has never been hacked - you might say it's a huge outlier but it is possible to do well.

cmdrfred 10y ago
I'm building a chat platform with js and https crypto. It's better than nothing in my opinion.
- JustSomeNobody 10y ago
  A false sense of security is worse than nothing at all.
  - cmdrfred 10y ago
    Is it worse than just Https? I'm not advertising the feature loudly, I just want to keep nosy sysadmins on corporate networks with https inspection out of private conversations. It obviously can be broken by NSA types if they want to actively alter traffic, but passive monitoring should be harder. Also this forces the attackers hand, an attack against this system can be detected if you want to spend the time comparing hashes.
    - forgotpwtomain 10y ago
      > Also this forces the attackers hand, an attack against this system can be detected if you want to spend the time comparing hashes. You could have an extension which checks the hash of the js/html payload against a publicly known and signed hash prior to running and rejects it otherwise. It's still browser crypto but potentially you do better than 'everything is broken if the ssl session is hijacked'.
  - bigiain 10y ago
    True - and it's complex - but you need to keep the capability of your adversary in mind. This will thwart your nosy flatmate/little-brother. This is reasonably likely to keep curious or nosy corporate IT or HR staff at bay if you use it at work. It's not going to keep a properly authorised and resourced corporate IT investigation/surveillance out - at least not for any hardware that's got corporate ssl roots installed (or device management that allows installation of those). It'll likely keep local cops out. It's less likely to keep feds out if they're determined. It 100% will not help against people who've got browser trusted ssl signing roots and the ability to run QUANTUM on exploited backbone routers to deliver their own versions of the javascript appropriately ssl encrypted to you before the actual site has a chance to respond.
    - cmdrfred 10y ago
      Another vector is I won't really be able to respond to requests from law enforcement because as soon as the chat is over (or on request of the creator of the chat) I wipe the key from memory. Leaving only encrypted blobs in the database that are then purged themselves at a later time. The key is never written to the disk to prevent forensic analysis there as well. As a bonus, I can handle a decent number of users with a small amount of hardware as most of the hard work is done client side. Lastly, I'm planning on implementing all of the best protections we have against man in the middle attacks currently like subresource integrity and HSTS. If the browser committees give me something better (maybe some sort of resource signing that can be verified on a secondary secure channel?) I'll implement it. So it may protect against more in the future.
      - bigiain 10y ago
        That kind of policy didn't work out so well for Ladar Levison at Lavabit when they wanted to subvert the entire userbase's security just to get access to Snowden's email account... If you piss off important enough people - law enforcement won't just go away when you say "the system isn't capable of doing that", they'll say "so re-write the system so it is, and if you tell anybody we'll put you in jail forever". The FBI have seized and continued to run a child porn website before to gather evidence - do you _really_ think they'd hesitate before taking over your encrypted chat servers if they thought it'd get them a career-advancing prosecution? Do you think you'd fight as hard as Ladar did when the guys with guns come knocking at your door? (I have no doubt I'd cave pretty quickly - I've got a lot of respect for Ladar's resistance to selling out his users...)
bigiain 10y ago
No no - it's most likely a "good thing"(tm) It's not like I trust my browser and https any less than I trust my phone's baseband processor and it's NSL-able telco-end backdoorability...
hahooooo 10y ago
The issue is like this. I load https://webmail.example.com https://webmail.example.com. I see my email. My ISP doesn't see my email. The NSA (or anyone else who can MITM https, such as my workplace, college, etc.) can effectively turn it into http, and see the content. We need to fix that. So I write an encryption library in JS, loaded from https://webmail.example.com https://webmail.example.com . It loads the email through an AJAX call from https://webmail.example.com https://webmail.example.com, decrypts it, and displays it. The only issue is that whoever can MITMed the connection can also modify the JS file to send the key to a C&C server. So: "Dumb" ISP can't read #1 mail "MITM" ISP can read #2 mail So what's the gain? The only concern is that it's an active attack vs a passive attack, so no plausible deniability. But in most MITM scenarios, you don't need plausible deniability. 1. Your workplace computer and the connection is owned by them, so they can do what they want with it. 2. Dictatorships give themselves whatever powers they want 3. The NSA has enough side-channel attacks to exploit. So in which situation will a "JS" encryption help?
- jnbiche 10y ago
  > The NSA (or anyone else who can MITM https, such as my workplace, college, etc.) can effectively turn it into http, and see the content. To be clear, unless NSA has some massive capabilities we haven't dreamed off, properly implemented HTTPS cannot be MITM'ed (via SSL stripping, or other means) by anyone who lacks access to your local machine. Specifically, by properly-implemented SSL, I mean: 1. Serving https only, no http 2. HSTS 3. Certificate pinning The situation you mention regarding workplace computers is a little different from the NSA, since they have the explicit authority and ability to install root certificates on your local work computer. Without those root certs (like if you use a personal computer at work), they lack the ability to MITM your connection, assuming the above.
  - bigiain 10y ago
    If I'm the NSA, I'd already have stolen Protonmail's HSTS pinned cert's private key (possibly by burning a zero day getting into one of their web servers, possibly by "asking nicely" to some tech employee there for whom I had appropriate leverage). But yeah - short of nation-state or very high level LEO (who're just piggybacking on their local NSA equivalent), HSTS with pinned certs is as close to "secure" as we have right now.

cmdrfred 10y ago

I'm building a chat platform with js and https crypto. It's better than nothing in my opinion.

JustSomeNobody 10y ago
A false sense of security is worse than nothing at all.
- cmdrfred 10y ago
  Is it worse than just Https? I'm not advertising the feature loudly, I just want to keep nosy sysadmins on corporate networks with https inspection out of private conversations. It obviously can be broken by NSA types if they want to actively alter traffic, but passive monitoring should be harder. Also this forces the attackers hand, an attack against this system can be detected if you want to spend the time comparing hashes.
  - forgotpwtomain 10y ago
    > Also this forces the attackers hand, an attack against this system can be detected if you want to spend the time comparing hashes. You could have an extension which checks the hash of the js/html payload against a publicly known and signed hash prior to running and rejects it otherwise. It's still browser crypto but potentially you do better than 'everything is broken if the ssl session is hijacked'.
- bigiain 10y ago
  True - and it's complex - but you need to keep the capability of your adversary in mind. This will thwart your nosy flatmate/little-brother. This is reasonably likely to keep curious or nosy corporate IT or HR staff at bay if you use it at work. It's not going to keep a properly authorised and resourced corporate IT investigation/surveillance out - at least not for any hardware that's got corporate ssl roots installed (or device management that allows installation of those). It'll likely keep local cops out. It's less likely to keep feds out if they're determined. It 100% will not help against people who've got browser trusted ssl signing roots and the ability to run QUANTUM on exploited backbone routers to deliver their own versions of the javascript appropriately ssl encrypted to you before the actual site has a chance to respond.
  - cmdrfred 10y ago
    Another vector is I won't really be able to respond to requests from law enforcement because as soon as the chat is over (or on request of the creator of the chat) I wipe the key from memory. Leaving only encrypted blobs in the database that are then purged themselves at a later time. The key is never written to the disk to prevent forensic analysis there as well. As a bonus, I can handle a decent number of users with a small amount of hardware as most of the hard work is done client side. Lastly, I'm planning on implementing all of the best protections we have against man in the middle attacks currently like subresource integrity and HSTS. If the browser committees give me something better (maybe some sort of resource signing that can be verified on a secondary secure channel?) I'll implement it. So it may protect against more in the future.
    - bigiain 10y ago
      That kind of policy didn't work out so well for Ladar Levison at Lavabit when they wanted to subvert the entire userbase's security just to get access to Snowden's email account... If you piss off important enough people - law enforcement won't just go away when you say "the system isn't capable of doing that", they'll say "so re-write the system so it is, and if you tell anybody we'll put you in jail forever". The FBI have seized and continued to run a child porn website before to gather evidence - do you _really_ think they'd hesitate before taking over your encrypted chat servers if they thought it'd get them a career-advancing prosecution? Do you think you'd fight as hard as Ladar did when the guys with guns come knocking at your door? (I have no doubt I'd cave pretty quickly - I've got a lot of respect for Ladar's resistance to selling out his users...)

bigiain 10y ago

No no - it's most likely a "good thing"(tm) It's not like I trust my browser and https any less than I trust my phone's baseband processor and it's NSL-able telco-end backdoorability...

hahooooo 10y ago

The issue is like this. I load https://webmail.example.com https://webmail.example.com. I see my email. My ISP doesn't see my email. The NSA (or anyone else who can MITM https, such as my workplace, college, etc.) can effectively turn it into http, and see the content. We need to fix that. So I write an encryption library in JS, loaded from https://webmail.example.com https://webmail.example.com . It loads the email through an AJAX call from https://webmail.example.com https://webmail.example.com, decrypts it, and displays it. The only issue is that whoever can MITMed the connection can also modify the JS file to send the key to a C&C server. So: "Dumb" ISP can't read #1 mail "MITM" ISP can read #2 mail So what's the gain? The only concern is that it's an active attack vs a passive attack, so no plausible deniability. But in most MITM scenarios, you don't need plausible deniability. 1. Your workplace computer and the connection is owned by them, so they can do what they want with it. 2. Dictatorships give themselves whatever powers they want 3. The NSA has enough side-channel attacks to exploit. So in which situation will a "JS" encryption help?

jnbiche 10y ago
> The NSA (or anyone else who can MITM https, such as my workplace, college, etc.) can effectively turn it into http, and see the content. To be clear, unless NSA has some massive capabilities we haven't dreamed off, properly implemented HTTPS cannot be MITM'ed (via SSL stripping, or other means) by anyone who lacks access to your local machine. Specifically, by properly-implemented SSL, I mean: 1. Serving https only, no http 2. HSTS 3. Certificate pinning The situation you mention regarding workplace computers is a little different from the NSA, since they have the explicit authority and ability to install root certificates on your local work computer. Without those root certs (like if you use a personal computer at work), they lack the ability to MITM your connection, assuming the above.
- bigiain 10y ago
  If I'm the NSA, I'd already have stolen Protonmail's HSTS pinned cert's private key (possibly by burning a zero day getting into one of their web servers, possibly by "asking nicely" to some tech employee there for whom I had appropriate leverage). But yeah - short of nation-state or very high level LEO (who're just piggybacking on their local NSA equivalent), HSTS with pinned certs is as close to "secure" as we have right now.