Imagine if they had tried this with their corporate customers.
My advice to home users would be to disconnect their Windows computers from the internet and use some other OS for tasks that require internet. Use Windows offline for the graphical tasks that Microsoft was founded on.
I remember the days before Windows had a TCP/IP stack. Gates did not see the point in the internet or www immediately. UNIX computers were connected over the phone lines. Windows computers were not. Gates eventually woke up and MS copied the TCP/IP code they needed from BSD. The rest is history. Look at them now.
One should not need an internet connection to run Excel and create spreadsheets. If one needs to send a spreadsheet to some remote computer, there are other operating systems that can do that. Such as the one from which Microsoft copied the TCP/IP stack.
Or, do exactly this with an offline windows VM on a POSIX host. Even with enabled file sharing it should be reasonably secure in terms of privacy and at the same time convenient. The only usecases where this is not ideal: gaming and graphics heavy applications.
"I should be able to see what data an app is sending..."
And you can. There are many ways. Something as simple as 2 socat instances and netsed works great as a quick and dirty but very robust solution. See also sslsplit which will generate certificates on the fly.
Anyone who is telling you that you can place complete trust in the use of x509 certificates on the open internet is either naive or dishonest.
You should read up on how certificate pinning works. Obviously you can still decompile and recompile the app with different certificates baked in but it's a bit more difficult than what you're implying.
Any device that prevents a user from installing their own CA root cert is not one I would use. I'm not sure if they have started to do this or not.
In terms of protecting users, there's no valid reason the owner of the hardware should not be able to control the list of endpoints that she has already authenticated and is willing to trust.
It would be like if SSH did not allow the user any control over known_hosts or to decide that she will accept or not accept a connection.
The entire point of certificate pinning is to ignore the certificates the user installs... Nothing to do with the operating system at all. If the software doesn't want to connect because the wrong certificate is presented to it that's where it ends. You can install as many local roots as you want, it won't change a thing.
So if the user does not want to trust a certificate installed by someone else on the device, she can "revoke" it?
And by the same token if she wants to explicitly trust a certificate, regardless of who installed it, she can do so?
Does the user have control of the process of "trust" or not?
The entire point of the device, OS and apps is to benefit the user, not some third party trying to hide data being sent from the device... from the user.
Do you believe a user should be able to "MITM" her own traffic or not?
> Do you believe a user should be able to "MITM" her own traffic or not?
I do, but that is utterly irrelevant to this discussion. We are discussing what certificate pinning is and how it works.
You can currently perform certificate pinning on every single operating system you can imagine. You can do this in a way that completely ignores the trust store of that operating system, and anything the user does to this is ignored by the application.
This has been possible for years on Android. This has been possible for years on Windows. This has been possible for years on Linux.
All the developer has to do is include the certificate of their own CA with the application, restrict the SSL's trust store to this one certificate, and then also check the fingerprint of the resulting certificate offered by the server. Then if the application notices this fingerprint is incorrect, it bails.
This is reality. This is how it works. Nothing I believe or want will change this. No amount of certificates I install in my operating system's trust store will change this either.
What android is doing is making MITMing yourself harder. But it's always been 100% possible for developers to make MITMing impossible without first reverse engineering the app and replacing the baked in certificate.
"What android is doing is making MITMing yourself harder."
That's not good for users.
I do not rely on Android, Windows or Linux. Not really much an app user either.
But if I were a user of these systems I would avoid apps where the user is not allowed to see what is being sent. Irrespective of any justifications put forth. By a company that relies on collecting personal information and selling advertising to make money.
Yeah, no shit. But that's not my, or your, point. Do you even have a concrete point you're getting at, or is it just "I don't like Google"?
Android is making it MITMing apps harder if the application itself did not attempt to make it hard. It has ALWAYS been possible for applications to pin their certificates and to make MITMnig them a pain in the butt. On every OS. On Windows. On Linux. On Mac. On iOS. And yes, on Android too. It has always been that way. I already went over this. Here, go read this: http://security.stackexchange.com/questions/29988/what-is-ce...
But, there is a solution! One that they (Google) also clearly indicated in the blog post when they announced this whole thing. And that solution is: Install a custom rom which does not have these security features. Bam. Done! That's all it takes. If you care about your privacy you're already running a custom rom. And if you care about MTIMing apps, then installing a custom ROM is not that much of a hurdle either.
OK, then how do we separate the data that is his versus data that belongs to somene else? Maybe we would have to look at what is being sent from the app?
Who knows? The two things are unrelated. My comment wasn't anti-reverse engineering, just stating a fact: just because something is in your phone doesn't mean it's yours.
I have always liked the download.gmane.org option. I rarely use the web interface.
I hope download.gmane.org does not disappear.
Gmane is a truly great service. IMO, it does not need to be part of "the web". It's better than that. It's part of "the internet". One of the best parts.
Any similar projects aimed at compiling Linux binaries on non-Linux Unix? (Excluding qemu, etc.)
Some non-Linux Unix have Linux emulation and can translate a subset of Linux syscalls. Perhaps it could be in a chroot with all the needed Linux libraries and utils.
But I am curious if there have been existing projects aimed at this goal.
What if Zuckerberg had received a cease and desist letter when he was accessing computers without authorization at Harvard?
Before any student willingly sent him personal information, he had to exfiltrate such information i.e. photos of other students so other students would be compelled to look at websites he created using said photos.
He did eventually receive a cease and desist letter, and he ignored it. But of course it was not from the people charged with protecting students' personal information nor the students themselves. You know the story.
As with Google, under today's culture it's acceptable for Facebook to aggressively collect personal information in bulk and pay little attention to obtaining permissions, but it is not acceptable for anyone to attempt to collect information in bulk from Google or Facebook. This make no sense to me, but I gues I am just obtuse.
Maybe what Kerr is wondering is when the necessity of sending costly snail mail cease and desist letters will give way to some less expensive digital form of notice. When that happens, the threat of the CFAA can be used on a mass scale. Perhaps then we would see it in every Terms of Service. Maybe we could create a new HTTP response code: HTTP/1.1 606 CFAA Notice.
"For instance it doesn't have everything you need to validate certificates..."
Yet it has all the CA crap thrown in, via the overloaded openssl binary. As "examples". And according to the documentation, not even "correct" illustrations of how libssl should be used.
Encryption and authentication are two separate problems.
Just because you figured out a way to encrypt a message does not mean you have also figured out how to a way to send it to only the correct recipient... over an insecure network. (Insecure not only in the sense of "plaintext" but in the sense you are not in control of much of anything - routing, PKI infrastructure, etc.)
It seems to me that one would want to solve the authentication problem first, and then move on to encryption.
This comment shows that for proponents of using SSL on the public web, it's been the other way around. Authentication was never sorted out.
When it comes to authentication, all due respect to the OpenSSL authors, SSH has provided a better attempt at a solution than any implementation of PKI using SSL/TLS.
And one more thing, how many ciphers does a user really need? As we've heard time and again, many of them are not even "safe" to use. Some of the alternative SSL libraries have wisely removed them. But I guess OpenSSL is append only?
I guess the way to test your theory would be to look at users who had IRC to use and nothing else -- no choice.
The truth I believe is that users adapt to whatever software they must use.
Before the "UI/UX" hype began, before there was Javascript, a long time ago, not as many people had to use computers. It was optional. Many people were computer illiterate and it had little to no impact on their life.
Now today, we all know that users no longer have to learn about the command line or configuration files. Everything has been made very easy to fall into. Click or touch an area of a screen and something happens. Great.
But... what I see many commenters fail to recognize is that the increase in computer usage since those times has little to do with interfaces and everything to do with the need for everyone in a civilized society to use computers. Because today computers and computer networks are much more powerful, and more useful. They have become a necessary part of everyday life for the civilized world.
No one in these societies can claim computer illiteracy anymore.
So users learn what they have to in order to get by. This was the same in the 1990's as it is today. Today the amount of learning required to use a computer is almost nil.
But if a user, whether in 1992 or in 2016, had to use a computer out of necessity, and the commmand line was the only way to control the computer, you can bet they would learn it. Technical ability nothwithstanding.
I have seen this with my own eyes. A lot of the talk about what users want and don't want, or what they will and will not do is all in the mind of the developer.
The truth is people today are forced to use computers. They'll use what they are given. And no user is ever forced to learn to use the command line in order to use (be used by) a computer.
But if today's users were forced, they could do it. And they would do it because use of a computer has become a necessity.
Also, people born after 1993 have no fear of computers. They'll learn anything that is put in front of them. It just so happens that what is put before them is a boatload of "UI/UX" hype. They take the bait - hook, line and sinker. No surprise.
Computer usage has changed since the birth of IRC but it has nothing to do with "UI/UX". There was a time when people in the civilized world could abstain from using a computer; that time has passed.
My advice to home users would be to disconnect their Windows computers from the internet and use some other OS for tasks that require internet. Use Windows offline for the graphical tasks that Microsoft was founded on.
I remember the days before Windows had a TCP/IP stack. Gates did not see the point in the internet or www immediately. UNIX computers were connected over the phone lines. Windows computers were not. Gates eventually woke up and MS copied the TCP/IP code they needed from BSD. The rest is history. Look at them now.
One should not need an internet connection to run Excel and create spreadsheets. If one needs to send a spreadsheet to some remote computer, there are other operating systems that can do that. Such as the one from which Microsoft copied the TCP/IP stack.