pencilo's comments

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.