pencilo

You're thinking of https://android-developers.googleblog.com/2016/07/changes-to...

Locally added CAs override pinning, so no it wont help.

The evidence that he paid for murders is as damning as the rest of it, he kept the chatlogs and made diary entries about _paying to have someone murdered_, Please.

The fact that he was scammed and no one was murdered is irrelevant, completely and utterly, and only goes to show he's not as smart as he thought he was. He's still just as evil for trying and it more importantly celebrating when he was told it was successful.

Agreeing with tptacek, again, pretty sure your last statement is false.

You see he's ok because he writes code and drug laws are bad, man.

I'm disgusted by people trying to claim he is anything but a horrible person while trying to brush away the fact that he paid for people to be murdered. Sure, no one was killed, but that's only by the grace of his stupidity, and massive ego.

HN might hate the war on drugs and love people that write code and live in the valley but its embarrassing that self described smart people could fall so low as to latch on to that while ignoring the undeniable horrible things he did. He wasn't a smart guy, he wasn't a good guy, its like people didn't read the transcripts where they went through his journal detailing everything he did.

Sorry I wasn't clear, I wasn't talking about someone MiTM but someone actively compromising their servers.

It would be nice to have a corpus of javascript and HTML from these sorts of sites so that someone could go and look for these kinds of attacks but I doubt you can do anything proactively without destroying the ability to launch features/do experiments. Certs change rarely so pinning works, content not so much.

They don't make ProtonMail worse per se but I'm a little worried when people bill bad security ideas as core security features, it makes me cautious about anything else that could be problematic.

I don't think any of these challenges make ProtonMail a mistake though. It's certainly always going to be better than GMail, which depends on access to your message plaintext for advertising, and therefore can never provide privacy.

No email provider whose main interface is a browser ever can provider you with those promises of privacy though, at least GMail doesn't claim it when they can't really promise it.

Since I'm the first security person here I might as well just start off the anti-javascript crypto thread:

Their claim "Zero Access to User Data" is completely untrustable. There is no realistic way to be confident that this time you logged in you didn't get served backdoored javascript that sends that 'local browser only' password up to the server. This already happened in the past with Hushmail so you should keep this attack in mind.

Any system that is based on crypto code that you get in this way is inherently silly and doesn't buy you anything if the server is malicious, which is all this feature is billed as. At best you gain nothing, at worst you gain false confidence in your security.

The Swiss bit sounds interesting, but I know nothing about Swiss law and I don't see how that would stop active exploitation by an outside state actor from breaking into their service and exploiting the fact that the crypto code is sent down every time you page fetch(after a login even, how nice for targeting!). That's one of the NSA's major roles, I doubt they'd have much issue pulling it off if they wanted/needed to.

Yes but worse, this is basically a 1990s anti virus + hype.

"Relatively poor" is letting them off easy, comically incompetent would be closer to the truth. Hopefully Square doesn't trust data from Snapchat.

Lucky for Snapchat their users and potential investors don't care about security in the slightest.

The code used for the paper is actually here: https://github.com/pencilo/ssl

I quit gradschool a month after publishing this so can't comment on what Suman is currently working on, but it looks like it is still mostly my code for generation.

I didn't write the script for using polarSSL but I wrote most the other ones,the testing harness, cert generation and cert crawling, and I can say that polarSSL loved to crash on my weird certs. I almost wanted to remove them from the tested list for being so unreliable.

How could I possibly verify that though?

Case 1: You delete my message once I read it Case 2: You simply report it as deleted once I read it(but keep it stored)

Is there any way for us to distinguish the two?

The more important part of my post was "What stops Delete.im from saving your messages?". What if you get an order from your government's legal apparatus to save my messages?

This isn't about hackers or even the NSA. The NSA is like the final boss. This isn't even passing level one.

The point is that you don't actually offer me any more privacy than if I just used the 'Off The Record' feature of many chat programs or deleting my logs.

Are 'off the record' conversations deleted the second they fall off your chat history? I doubt it. Are delete.io messages deleted once the server started returning 'this message is unavailable'? I doubt that too. More importantly I can't verify if you delete them then or even at all.

Now my sensitive data is not lying around in my chat history or emails, it is lying around on your server. If my logs are only stored locally I can delete them. Likewise if I control my email server I can delete them.

How can I prevent sensitive data lying around on your server? Are you more trustworthy than my email? Why?

The comparison to Snapchat and friends comes from the 'limited number of views' or 'viewable only for a time' feature. These features are trivially broken at best and misleading to non-technical people. These are marketed as privacy features and they're a lie.

If you want to bill your service as a pastebin style service that removes files after a time then go right ahead, I will not have issues with that.

If you want to claim that those features are to protect sensitive data? Then I have a problem. Services built around working with sensitive data need to be held to a higher standard.

That worked so well for people using hushmail.

http://en.wikipedia.org/wiki/Hushmail#Compromises_to_email_p...

These services deeply anger me and it is pretty hard not to launch into rants when I see them unfortunately.

I have an honest question for you HN: Do you not see these services as fundamentally broken? Would it be worth writing a long post somewhere breaking down exactly why these services are broken at best and bad in general? I'm deeply afraid that the public will start seeing these services as providing actual privacy and start using them as such.

How do you know there is no paper trail? What stops Delete.im from saving your messages?

The main thing to point out is that by uploading a message it is still possible to get access to your message in a permanent state either by screen shotting or finding the image source. The tool exists for people who have no interest in keeping the messages you send. Please don’t blame us for message leaks.

So I can't send this to people I dont trust and I have no way to guarantee that delete.im doesn't save my messages. What exactly do I gain from this over just clearing my local logs?

As as security person these 'forgetful' services really bother me because people tend to claim that they offer the world but there is no way to actually guarantee any of it. More importantly there _fundamentally_ isn't a way to prevent the other side from saving the message. Without end-to-end encryption there isn't a way to make any claims about what is stored by the service.

And before you recommend end-to-end encryption in a browser based service don't forget that we know exactly how those get MITM'd: When a warrant comes in you serve that person a different webpage with broken encryption/leaks.

This is the same rant I had about Snapchat, and the same rant I'll have about the next forgetful .* service. The only claim they have to actually being forgetful is a promise and you'll never see them stand behind any actual privacy claim because they cant and they know that.

tl;dr Please stop making 'forgetful' services or 'view only once' services.

As a security person I enjoy blaming the NSA and conspiracies as much as anyone.

That said sorry but I don't buy this. Just seeing a diff with that one + makes me more inclined to believe there was an if(...) goto fail that someone removed without removing the statement as well.

There is more than enough incompetence in our industry that a deliberate job is completely unnecessary, why bother when engineers break security all the time anyways?

You don't need fancy software, compilers warn about this kind of thing.

SSLVerifySignedServerKeyExchange in http://opensource.apple.com/source/Security/Security-55471/l...

If you want to see my favorite SSL bug ever.

Take a look at http://opensource.apple.com/source/Security/Security-55471/l...

specifically check the function SSLVerifySignedServerKeyExchange

I leave the joy of spotting it to you. It is obvious and if you know c you'll see it(You don't need any knowledge of crypto).

The key is a constant in the application, while ECB is embarrassing the mode can't help you here.

But if it makes you feel better you can upload arbitrary bytes to Snapchat, encrypt it with your own not-stupid method.

Chad here.

First off I'd like to give props to the gibsonsec.org guys, that is a really high quality protocol breakdown and the attack is neat. I see nothing wrong with going full disclosure after being ignored this long.

The key point is to understand that I, as a protocol reverse engineer/attacker/professional bad dude have access to _everything_ the Snapchat app has. I own the network and the device the app is running on. I can look at every bit of Snapchat's memory space if I want.

I can view all network traffic between the app and the servers. Either by MITMing the app or if the app has cert pinning nothing stops me from peaking at buffers(I did this with Square, it was actually not that painful).

With just that you can see it is not possible to stop me from saving a Snap. I don't even need to make my own API calls, I can simply intercept the traffic of the actual Snapchat client and pull the image out of there. Even if you had a magical way to make sure only the actual app was requesting the Snap it wont help, it is the legit client.

The more important take away though isn't that Snapchat is broken, because that's not super interesting.

What you should take away from Snapchat is that you cannot stop people from calling your remote APIs that your apps are using. All it takes is someone sufficiently bored to go dig through pcaps and decompiled code to map out the API.

So what do you do? Don't trust the damn client. Your service shouldn't be broken just because I am calling your API outside of the bounds of how your application will call them.

This isn't a new idea, but it seems like a lot of people never learned this lesson.

There is an important difference between what Snapchat needs and what game designers need.

First of all, look at what is actually successful for DRM in video games. The only surefire way to make sure someone is actually valid is to force them to authenticate(and get data from your server) to play the game. To do this they'll need to provide credentials(like a CD key) and then they'll get the content[1].

Now look at Snapchat. At no point do we need to fake having valid credentials. We are coming in and presenting valid credentials to Snapchat, my login and password, and it verifies those are correct and begins a sessions.

If you want an analogy to game DRM you need to look toward things like hacked clients in MMOs.

tl;dr Games want to prevent people without valid credentials from playing, we have valid credentials already(our own accounts). [1] This is really simplified and you can find many games, like the new SimCity, that the server interaction is small and simply emulated in the crack.

You're slightly wrong on the app side of things and the keys.

There are in fact two 'secret' keys. One is a fixed SHA256 hash used for their weird request generation and one is the fixed AES-128 key for encrypting snaps. The two have nothing to do with each other besides both being named secret.

Also it was not ctrl+f for secret as much as it is looking at the call sites for calls down into crypto libraries, from there it is simple back tracing to see where the keys came from. Debug symbols are nice but it works just as well if they strip debug symbols and obfuscate.

Hi, one of the authors here. A good chunk of the core is from my python Snapchat API(https://github.com/pencilo/pysnapchat) which lets you do things like download snaps and send snaps.

You are correct that it is impossible for them to stop you from downloading the image and saving it. Images are encrypted on upload but they are encrypted using a fixed key in AES-128 ECB, so it doesn't do any good.

The simple truth with Snapchat is they cannot make it impossible to download and save the images without trusted computing support(which they wont get).