Is the mid-range market really big enough to be worth them investing a lot in though?
In my experience (warning: anecdotal evidence detected) the people who "just want a phone that can call and text" won't pay the extra for a mid-range device as they don't need nor want the extra features (the current economy has put pay to there being many people who get something a bit better than they currently need just-in-case), and most people who want a smart-phone want a high-range one either because they need/want the capabilities of one or because they are keeping up with the Joneses.
They are not paying MS. The deal works out that they get a large pile of MS money to develop their Window Mobile range, at least initially. Joining the Android market late would have put them in the "plucky newcomer" category competing against the established leaders in that arena like HTC, so in the Windows Mobile world they have more chance of a level playing field in that arena and more chance of a little control to nudge things in the direction they think best than they'd have with Android (ignoring the forking option, which wouldn't work well for them any more than what they were previously doing to try replace Symbian).
Well, they weren't doing that good a job of competing in the smart-phone business before the MS buyoutdeal. The oft quoted fact that Symbian phones outnumber iPhone and Android combined is no longer the case (just) and the Symbian share is falling rapidly. The 80+% share of the smartphone market in 2008/2009 included other manufacturers (not just Nokia so that 80% should not be taken as meaning Nokia had 80% of the market) but all the others have since dropped Symbian from the new ranges, Nokia is just the last to do so. They were no making significant money on the smartphone market despite all the investment (some of it misguided as they had teams effectively working on things that had been solved already elsewhere) they were piling into developing stuff.
OpenSSH still works fine using the equivalent of self-signed certificates.
You seem to be misunderstanding the SSH protocol in this case, and seem to be assuming it protects you in a way that is doesn't. The intention is that you know the server fingerprint by some means (i.e. is has been transmitted to you by a method other than the connection to that server) before your first connection or you are absolutely 100% sure that there is nothing between you and the server that you don't control when you make that first connection. If you blindly accept the fingerprint of the server's certificate the first time you connect without verifying it via another source then you have absolutely no definite assurance that you are talking to the right machine rather than a nefarious one. Once the certificate is accepted SSH protects you from MitM and other attacks by protecting you against the certificate changing (unless there is a significant breach at the server, a MitM attacker won't be able to replicate the keys so their fingerprint should never match), but is does not protect you at all on first connection unless you verify the fingerprint before accepting it.
The SSH method is not practical for a public HTTPS service as you have no practical way of transmitting the certificate fingerprint to every user beforehand for them to verify (and for a private HTTPS service, create your own CA key for signing certs and have your users install that in their browser trust lists).
What OpenSSH protects against is unexpected changes to the certificate, and the certificate being wrong initially if you properly verify the fingerprint (rather than blindly accepting anything) on first connection.
HTTPS with a properly signed certificate protects all connections, even if you can not verify the certificate by other means yourself on first connection.
A number of ISPs seem to think that snooping on their customers' traffic for things like Phorm is acceptable. How many of them would think they could get away with forging SSL certificates?
I don't see why they wouldn't. How would most users even know it had happened? The cynic in me suggests that the only reason some don't do this already is that not enough marketable information is transmitted that way for it to be worth the effort - if a higher proportion of traffic worth scanning (for selling to advertisers and such) was via HTTPS with self-signed certs then maybe some would start.
On every connection their customers make?
It would not need to be that inefficient. Just keep a cache of certificates that you have generated, so you only have to do the generation step once per server name. OK so you still have to do the decryption and re-encryption on the scanning proxy as the stream passes through, but that isn't an expensive operation with modern hardware.
I could name one company (a defence contractor) who does this in their transparent proxy for all outgoing connections so they can monitor for trade/state secrets being passed around that way (and their machines trust their own internal CA cert, so the proxy can generate valid looking certs for anyone's services (even, for instance, Google's) and browsers on their network wouldn't know). It is possible and practical, so if it were in some way profitable for ISPs to do this with self-signed certs they probably would.
I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections.
The benefit is small though, and there is a potential significant cost to accepting self-signed certs without warning. If I somehow poisoned your ISP's DNS server (there have been bugs in bind in the past that made such attacks easy) so that connections to gmail went through my server, I could self-sign a certificate with the right name and forward the connections on. In this case you would not know that som
What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of?
Probably none, because I don't believe that any browser ships with support for StartSSL and hence will treat it as an unsigned key.
http://en.wikipedia.org/wiki/Startssl#StartSSL - it would appear that StartSSL's root CA cert is trusted by most common browsers according to that article, though I've not verified this in any way myself yet. If I'm understanding right then the only major population of users with an up-to-date browser that don't have their key trusted is those using IE on XP who have not installed the "certificate update" patches (which aren't marked as important so don't auto-install). While there may be a number of groups of people with out of date setups, most will have browsers that trust a StartSSL cert and those that don't will get the same sort of warning (and lack of protection) as with a self-signed cert but won't be any more/less inconvenienced.
And regardless, firesheep doesnt screw with SSL cracking, it looks for unencrypted login cookies.
I was suggesting that someone may write something akin to firesheep that integrated the extra hacks required to attempt to MitM the SSL connection, and if/when that happens your self-signed connections are no safer than plain text ones.
It might be harder right now, as you can't just open up firesheep or similar and have it do the work for you, but as soon as someone releases a proof of concept attack that works via arp poisoning you can bet your last penny that script kiddies all over the world will be running the hack.
Given there are free certs with proper trust paths available that are accepted by the vast majority of browsers (http://en.wikipedia.org/wiki/Startssl#StartSSL is the only one I know of, but there may be others) there is no need for self-signed certs on public facing sites at all.
would force Apple to either stop signing binaries or hand over the keys
Or pay the project for permission to use the software under some different licensing?
Though that might not be possible, as with a large project with many regular maintainers and even more occasional patch submitters it can be difficult to know who owns what unless all contributors have signed copyright waivers so the project owns everything in that respect.
Exactly. Though it isn't really a MitM "attack" in their case as the behaviour of the proxy is well publicised internally so all staff should know about it.
This is why self-signed certificates should not be used outside a testing/development environment: anyone who hacks into a proxy at your ISP, anyone running a public internet access service, or anyone on the same wireless network who manages an arp-spoofing attack in order to setup a transparent proxy, or anyone who manages a DNS poisoning attack, can masquerade as your service as anyone can sign a "self signed" certificate for any domain and there would be no way of telling the difference if they were careful. With a certificate signed with a proper trust chain that leads back to a CA cert your browser trusts you are protected from this, as long as you trust your browser/OS's list of trusted CA certs.
It is certainly done in certain companies. I'll not mention the company name (though it is no secret really) but I have a friend who works for a defence contractor who work on MoD projects, and they do this to monitor outgoing HTTPS connections.
No machine that touches their network does so without running one of their locked-down OS builds, and all their builds include the certificate for their internal CA in the trusted list for the OS and any extra browsers. Once your CA cert is trusted by all your client browsers, automating the generation of "valid" certificates is not difficult. To reduce the speed impact of this their proxy maintains a cache of certificates rather than generating new ones for each request.
No doubt other businesses in that and other sensitive arenas do the same thing.
IMO that sort of mix would be pretty healthy. Safer than any one with a big advantage (that one would be able to cause the sort of hassle that IE6 has caused) or there only being two major players (with three, one can go through bad spot, including dying completely, without necessarily creating a situation where one of the others ends up with 60%+ market share).
Regarding your dialup provider: assuming you are dial-up due simply to nothing else being available in your area (rather than for cost reasons) and you have a few $/month spare you could rent a cheap VPS somewhere, install your own proxy software like http://ziproxy.sourceforge.net/, and use that instead of the ISP's setup. That should do image recompression in a way that is not browser specific, apply compression to textual content (html, css, scripts) that doesn't have it already, and so on. If your ISP does something to make this impossible (perhaps their proxy is transparent and so difficult to avoid) you might need to setup a VPN between you and your proxy (using OpenVPN, or perhaps just a SSH tunnel) to work around such limitations.
See my above reply... I don't disagree with you, nor does it sound like you significantly disagree with me.
Group in your #1 is not so very small, and they are the ones that will freak out and tell everyone on Facebook that your site hacked their computer when they get the security popup...
Aye. Loud-but-clueless people can be very difficult to ignore, much as we might like to try!
In another year or two hopefully everyone will be using SNI...
Or we might all be using IPv6 in which case the point is moot as practically every site name can have its own routable IP address anyway. Though SNI support being common enough that we can just ignore browsers without it is more likely to happen first (given that IE on XP is the only major problem in that area).
I know replying to my own post is often considered bad form, but I've spotted a sentence I failed to finish typing...
"then they are doomed to try do things." should be something like "then they are doomed to try do things that do not offer the security they think while diminishing the strength of existing protections or at least further confusing public thought about them."
He says 'it's still better than plain-text!' and you say 'Unfortunately that is not the case.' because you're been trained that it's not the case.
And then you are forced to actually justify why it's not the case, and end up say 'So it is a bit better than plain text'.
So, basically, you admit he's right, but you've been told over and over he's wrong, so you somehow think he must be wrong, even though you just admitted he was right.
No. No. And No. I said it is "a bit harder", in that an attacker needs to make slightly more effort to perform a MitM attack, but that this is not enough as such little extra effort is not much more difficult to automate than the session stealing trick used by the recent "plain http isn't safe even if you use https for login" demonstrations. I pointed out that it is in fact a bit harder otherwise I would have looked like the mindless drone you take me for in your misunderstanding, and described why his "a bit harder" simply isn't enough.
There is no justification for warning people about unsigned encrypted if you're going to let them do plaintext without a warning. Anyone who thinks about this has to admit that. Even people like you who can't admit it...have to admit it.
No, we do not have to. No we won't.
There is justification for warning people about certificates without full trust chains, and that is that using such certificates does not protect you from everything that certificates with full trust chains protect you from: namely proxy-based and/or arp poisoning based man-in-the-middle inspection/injection vectors.
Letting people use something called https that looks like https and acts like https without actually offering the same protection of proper https (i.e. without offering protection against the proxy based and/or arp poisoning based MitM attacks a self-signed certificate attacks that certificates with properly signed trust paths protect you from but self-signed certificates do not) will only lead people into a false sense of security. The warning exists because a self-signed certificate does not give the guarantees that one with a valid trust path gives, and it is right to raise the warning because this potentially renders the assurance offere by https completely invalid.
If you are in a situation where you do not control or otherwise explicitly trust every host on the route between you and the server and every host on the same network segments as all those hosts (including any within 100m if you are using public wireless), then browsing with https with a self-signed certificate is not significantly more secure than browsing with plain http. And there are very very few situations where you can guarantee that level of trust of the server and all the nodes and network legs between you and it can be justified. Claiming that the connection is secure in these cases by showing a little padlock and not warning the user that they do not have the full protection https could offer would be wrong.
but if you care enough about the content to use HTTPS in the first place then "a bit better" is not enough.
What a dumb statement. If you care enough about content to used signed HTTPS, then obviously unsigned HTTPS is not enough.
Of course, NO ONE IS TALKING ABOUT LOWERING THE SECURITY OF ANY SITE. The question was explicitly talking about currently-plaintext sites. As is the article. There's no any possible way to misunderstand this.
What a dumb response to my statement (sorry, I just did that to illustrate how invalid an ad hominem attack like yours is in these discussions). I'm not talking about lowering the security of implementations that already correctly using https, nowhere do I mention that I'm talking about lowering the security of existing https use. What I state quote clearly is that
Definitely still commendable. Dropping to script is a much better option than wigging out and completely panicking, perhaps making the situation worse.
1) Granny's not going to pay $100s per year for her blog.
Granny's block doesn't really need encrypting under its own name though (which is a fault in the question, rather than your answer). For reading it is no doubt public information that needs no protection. For protecting logged in sessions when she is making updates she is probably using a service like Blogger anyway and can edit using their domain even if she has her own domain name associated with the block for readers to access it through. Chances are she doesn't have her own domain anyway and her blog is themusingsofagranny.someblogsite.com or someblogsite.com/themusingsofagranny so her site can use the blog provider's (wildcard) certificate anyway. In no way should Granny need to pay for a cert for this. Anyway, startssl's free certs are accepted by the majority of browsers these days (http://en.wikipedia.org/wiki/Startssl#StartSSL).
2) Processing overhead. Security comes at the cost of speed.
The processing overhead is very small on modern CPUs - before the CPU becomes a significant bottleneck in this regard other parts of your infrastructure will have long since become a problem. There is extra latency in the initial negotiations, but that is only per session and should not be a problem for a decent web server, a decent client, and all but the slowest of connections. Content caching (or lack thereof) could be an issue, but proper use of cache-control headers will mitigate this for the most part (not something Granny needs to worry about - a good blog software setup should handle it without her even knowing the issue might exist).
Not quite correct: the CA cert used by startssl to sign their free keys is trusted by most browsers these days (see http://en.wikipedia.org/wiki/Startssl#StartSSL). Though you may find some XP+IE installs don't trust these certificates if the "root certs update" patches are not installed (these are not marked as critical or important in Windows Update IIRC).
2) SSL key exchanges are horribly expensive compared with serving a web page
The full certificate and key exchange only has to happen once per session so is not all that expensive overall. Even caching issues can be pretty much mitigated by proper use of cache-control headers for static objects (styles, images, scripts) and/or public content (html that contains no user specific information).
3) Right now EVERY web site would require a unique IP address
Only if you have to support users using XP+IE. Everything else of note (including IE on Vista/7 and other major browsers on everything including XP) supports Server Name Indication (https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication#Support) which removes the need for a 1-to-1 mapping of names to addresses for SSL purposes.
------------
The real reasons for lack of HTTPS on most sites/apps are:
1. Users stuck with XP+IE as their only browsing option (either due to ignorance of other options or because they operate in a locked-down environment that is out of date in that respect) and sites not wanting to alienate this (now very small) portion of the market
2. Mis-information and/or lack of knowledge of recent changes in the market on the part of developers and site/server managers.
3. Despite most web servers having supported SNI for a while, some common "web hosting control panel" software is not yet aware of it
4. A lot of content (i.e. truly public information) really doesn't need encrypting at all
I would love to see CACert in the default CA databases widely, that would help a lot.
The root certificate used by startssl to sign their free certificates is in most OSs' default list of trusted root certificates these days (http://en.wikipedia.org/wiki/Startssl#StartSSL). It might not be totally reliable for Windows users (for IE on XP at least it depends on them having the "root certificates update" patches installed, and they are not marked as critical or important so may not be installed everywhere), but seems to be an increasingly practical option as XP+IE market share continues to fall.
This is addressed using Server Name Indication (https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication) - unfortunately this is not supported by Internet Explorer when running on Windows XP.
If you are happy to potentially exclude that chunk of browsers (i.e. tell then to upgrade to Firefox/Chrome/what-ever for free, upgrade to Vista/7 at cost, just put up with the certificate warnings, or just go away) then the shared IP address issue is a solved problem.
I understand that a self-signed certificate is vulnerable to MitM... however, it's still better than plain-text!
Unfortunately that is not the case. If you are browsing on an untrusted network (free wireless for instance) a transparent proxy could be MitMing the certificate process be cause anyone can "self sign" a certificate for any resource name. That nefarious proxy could decrypt the content and re-encrypt it using keys for the cert it self-signed, and inspect & log the content on the way through. This could also be done by other users of the network (not just the network itself) if done in tandem with some sort of arp spoofing attack or similar which redirects your traffic to a proxy outside the normal routing path. So it is a bit better than plain text (intercepting the content is a bit harder), but if you care enough about the content to use HTTPS in the first place then "a bit better" is not enough.
SSH is a perfect example. When you first connect via SSH, you confirm that you trust the certificate. Your client then remembers the certificate for future use. Why doesn't web technology do this?!?
This relies on you always using the same machine(s) otherwise you constantly have to accept the server certificate (via acknowledging its fingerprint is correct). Unless you actually check that the fingerprint is correct this doesn't protect you from a MitM attack at all if you are accessing the service for the first time (or from a place you've not accessed it from before so don;t have the cert stored in your known_hosts file), so it wouldn't help the general public to whom you have no efficient and secure way to transmit the correct fingerprint to check the one presented to them against. What the SSH method does protect you from (in the case when you didn't properly verify the cert on initial connection) is when the certificate changes - i.e. it stops you connecting to a host that starts handing out a different certificate (or a host that is pretending to be that host so does not have the right private key) until you have verify that the change is legitimate.
Instead, when you self-sign a cert, browsers throw a hissy fit and shows a huge warning.
The SSH model would not work for HTTPS on public services (heck, the SSH model doesn't work for SSH quite the way many people assume it does!), and self-signed certificates have the proxy problem - this is why the warning exists. You can get free certs that are trusted by the vast majority of browsers, see http://en.wikipedia.org/wiki/Startssl#StartSSL for information and links to the one source I know of (to my knowledge no other free CAs like cacert yet have that level of acceptedness). You have to renew these once per year but that really is no massive hardship.
The things holding back the use of HTTPS for small services aren't the cost (basic certs can be bought very cheaply, often free, these days), the CPU hit (even in overcrowded VPS hosts, a modern CPU doing that work is not going to be one of the significant bottlenecks): they are
1. people still using Internet Explorer under Windows XP (so people running web services don't want to use SNI which is needed for SSL to work when you don't have a dedicated IP address per service name that needs a certificate)
2. a bit of ignorance on the part of the service providers and developers
3. potential caching issues which can cause extra load on the servers (but that would not be solved by the SSH-like solution on its own) though this can be mitigated by correctly marking static content with relevant cache-control headers (see http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https for some relevant discussion and links to more detail)
No: The way HTTPS works when the "recent" SNI feature is not available is that the TLS stream is created (including certificates being negotiated and verified) before any hostname information is transferred. This means that you can only have one valid certificate per publicly addressable IP address without SNI.
But yes: With SNI (see http://en.wikipedia.org/wiki/Server_Name_Indication for info) the hostname is sent earlier, so the server can lookup the right certificate for that name and send it instead of relying on a 1-to-1 mapping between IP addresses and service names.
Well, probably not quite yet: Unfortunately SNI is not completely supported by all common user agents, particularly any version of Internet Explorer running on Windows XP, so whether you can justify using the feature right now depends a lot on who your target audience are. If you don't have any users browsing your content/app with XP+IE or you don't mind telling such users to upgrade to FF/Chrome/other, upgrade Windows, or just put up with the certificate warnings, then using SNI will work for you. You run the risk of sending XP+IE users away though, which might not be acceptable if your bottom line relies on getting as much traffic as possible through your doors.
If your site doesn't expect me to login, register, provide any content or interact with it in any way that is not completely passive, then that is perfectly fine.
Otherwise: why should I bother interacting with your site in a less passive manner than simple browsing, if you can't be bothered to enable SSL? Enabling SSL is not difficult, does not generally cause a massive amount of extra load on modern systems (if your site is relatively dynamic then your scripting language and database will be much much more significant bottlenecks on a well designed site), and is not expensive these days (cheap SSL certs are now actually cheap and there are a number of free-for-a-year offers to be found at the moment).
Why should I do X so you can Y can work both ways.
I'd say security updates and new features and better support for more hardware. I mean, would you keep running Debian 2.2 on your desktop, which are both released about the same time?
No, but then there has been a "no need to completely reinstall everything" upgrade path all the way from Debian 2.2 and the latest stable release - this is one of the reasons my home boxes will remain on XP for a while yet. The hassle (i.e. cost) of producing and testing a new build is wy many big businesses will be running XP for at least a year more if not longer. Also for me as a home user, why would I spend £100 on a copy of Windows 7 Pro to replace my XP install when I could spend that money on something else that will actually give me a benefit worth spending the money on?
Regarding security updates: yes they would be the key reason to update. XP is set to get them until April 2014 - so if I've not upgraded or switched completely to something else by then I'll upgrade some time before the end of 2013. This is the main reason business users will upgrade/switch, and probably at about the same time too.
Features? I'm not aware of any that I'd pay the money (and time reinstalling) for. Yes there might be some things in Windows 7 that I'd like, but not so much that I'd pay for them. DX10/11? DX9 is working for me right now, and any game that I might otherwise pay for that dares not support XP simply relegates itself to being something I might buy (at a bargain price compared to the price soon after release) in two years time when I have switched from XP. IE9? Much as I dislike IE6/7/8 I can just use Firefox instead of paying to be able to use IE9 without my preferred plugins. And so on.
While IE use has fallen drastically in the last year or two, that 9% figure is going to include quite a bit of audience bias. Unfortunately for those of us who have to support IE professionally the amount of people using it in some audiences is much higher, and an irritating percentage of those populations will be using ancient versions for some time to come. One of our banking clients (one of the largest in the UK) is planning to roll out IE8 "some time this year". The rest of out clients (including others in the "largest in the UK" category are still IE6 only on company desktop and laptop builds.
IE9 would be good news (afterall, it is far more compliant then any version of IE that has gone before) if people using older IE versions switched to it. Unfortunately this is not going to happen as many people who are still using IE for day-to-day browsing either don't care enough to upgrade (hence aren't already using FF/Chrome/Opera/other, though if IE is pushed as an "important" update MS will catch most if the Vista/7 users automagically) and/or simply can't because IE9 will not run on XP.
Slashdot Mirror
Is the mid-range market really big enough to be worth them investing a lot in though?
In my experience (warning: anecdotal evidence detected) the people who "just want a phone that can call and text" won't pay the extra for a mid-range device as they don't need nor want the extra features (the current economy has put pay to there being many people who get something a bit better than they currently need just-in-case), and most people who want a smart-phone want a high-range one either because they need/want the capabilities of one or because they are keeping up with the Joneses.
They are not paying MS. The deal works out that they get a large pile of MS money to develop their Window Mobile range, at least initially. Joining the Android market late would have put them in the "plucky newcomer" category competing against the established leaders in that arena like HTC, so in the Windows Mobile world they have more chance of a level playing field in that arena and more chance of a little control to nudge things in the direction they think best than they'd have with Android (ignoring the forking option, which wouldn't work well for them any more than what they were previously doing to try replace Symbian).
Well, they weren't doing that good a job of competing in the smart-phone business before the MS buyoutdeal. The oft quoted fact that Symbian phones outnumber iPhone and Android combined is no longer the case (just) and the Symbian share is falling rapidly. The 80+% share of the smartphone market in 2008/2009 included other manufacturers (not just Nokia so that 80% should not be taken as meaning Nokia had 80% of the market) but all the others have since dropped Symbian from the new ranges, Nokia is just the last to do so. They were no making significant money on the smartphone market despite all the investment (some of it misguided as they had teams effectively working on things that had been solved already elsewhere) they were piling into developing stuff.
OpenSSH still works fine using the equivalent of self-signed certificates.
You seem to be misunderstanding the SSH protocol in this case, and seem to be assuming it protects you in a way that is doesn't. The intention is that you know the server fingerprint by some means (i.e. is has been transmitted to you by a method other than the connection to that server) before your first connection or you are absolutely 100% sure that there is nothing between you and the server that you don't control when you make that first connection. If you blindly accept the fingerprint of the server's certificate the first time you connect without verifying it via another source then you have absolutely no definite assurance that you are talking to the right machine rather than a nefarious one. Once the certificate is accepted SSH protects you from MitM and other attacks by protecting you against the certificate changing (unless there is a significant breach at the server, a MitM attacker won't be able to replicate the keys so their fingerprint should never match), but is does not protect you at all on first connection unless you verify the fingerprint before accepting it.
The SSH method is not practical for a public HTTPS service as you have no practical way of transmitting the certificate fingerprint to every user beforehand for them to verify (and for a private HTTPS service, create your own CA key for signing certs and have your users install that in their browser trust lists).
What OpenSSH protects against is unexpected changes to the certificate, and the certificate being wrong initially if you properly verify the fingerprint (rather than blindly accepting anything) on first connection.
HTTPS with a properly signed certificate protects all connections, even if you can not verify the certificate by other means yourself on first connection.
A number of ISPs seem to think that snooping on their customers' traffic for things like Phorm is acceptable. How many of them would think they could get away with forging SSL certificates?
I don't see why they wouldn't. How would most users even know it had happened? The cynic in me suggests that the only reason some don't do this already is that not enough marketable information is transmitted that way for it to be worth the effort - if a higher proportion of traffic worth scanning (for selling to advertisers and such) was via HTTPS with self-signed certs then maybe some would start.
On every connection their customers make?
It would not need to be that inefficient. Just keep a cache of certificates that you have generated, so you only have to do the generation step once per server name. OK so you still have to do the decryption and re-encryption on the scanning proxy as the stream passes through, but that isn't an expensive operation with modern hardware.
I could name one company (a defence contractor) who does this in their transparent proxy for all outgoing connections so they can monitor for trade/state secrets being passed around that way (and their machines trust their own internal CA cert, so the proxy can generate valid looking certs for anyone's services (even, for instance, Google's) and browsers on their network wouldn't know). It is possible and practical, so if it were in some way profitable for ISPs to do this with self-signed certs they probably would.
I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections.
The benefit is small though, and there is a potential significant cost to accepting self-signed certs without warning. If I somehow poisoned your ISP's DNS server (there have been bugs in bind in the past that made such attacks easy) so that connections to gmail went through my server, I could self-sign a certificate with the right name and forward the connections on. In this case you would not know that som
What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of?
Probably none, because I don't believe that any browser ships with support for StartSSL and hence will treat it as an unsigned key.
http://en.wikipedia.org/wiki/Startssl#StartSSL - it would appear that StartSSL's root CA cert is trusted by most common browsers according to that article, though I've not verified this in any way myself yet. If I'm understanding right then the only major population of users with an up-to-date browser that don't have their key trusted is those using IE on XP who have not installed the "certificate update" patches (which aren't marked as important so don't auto-install). While there may be a number of groups of people with out of date setups, most will have browsers that trust a StartSSL cert and those that don't will get the same sort of warning (and lack of protection) as with a self-signed cert but won't be any more/less inconvenienced.
And regardless, firesheep doesnt screw with SSL cracking, it looks for unencrypted login cookies.
I was suggesting that someone may write something akin to firesheep that integrated the extra hacks required to attempt to MitM the SSL connection, and if/when that happens your self-signed connections are no safer than plain text ones.
It might be harder right now, as you can't just open up firesheep or similar and have it do the work for you, but as soon as someone releases a proof of concept attack that works via arp poisoning you can bet your last penny that script kiddies all over the world will be running the hack.
Given there are free certs with proper trust paths available that are accepted by the vast majority of browsers (http://en.wikipedia.org/wiki/Startssl#StartSSL is the only one I know of, but there may be others) there is no need for self-signed certs on public facing sites at all.
would force Apple to either stop signing binaries or hand over the keys
Or pay the project for permission to use the software under some different licensing?
Though that might not be possible, as with a large project with many regular maintainers and even more occasional patch submitters it can be difficult to know who owns what unless all contributors have signed copyright waivers so the project owns everything in that respect.
Exactly. Though it isn't really a MitM "attack" in their case as the behaviour of the proxy is well publicised internally so all staff should know about it.
This is why self-signed certificates should not be used outside a testing/development environment: anyone who hacks into a proxy at your ISP, anyone running a public internet access service, or anyone on the same wireless network who manages an arp-spoofing attack in order to setup a transparent proxy, or anyone who manages a DNS poisoning attack, can masquerade as your service as anyone can sign a "self signed" certificate for any domain and there would be no way of telling the difference if they were careful. With a certificate signed with a proper trust chain that leads back to a CA cert your browser trusts you are protected from this, as long as you trust your browser/OS's list of trusted CA certs.
It is certainly done in certain companies. I'll not mention the company name (though it is no secret really) but I have a friend who works for a defence contractor who work on MoD projects, and they do this to monitor outgoing HTTPS connections. No machine that touches their network does so without running one of their locked-down OS builds, and all their builds include the certificate for their internal CA in the trusted list for the OS and any extra browsers. Once your CA cert is trusted by all your client browsers, automating the generation of "valid" certificates is not difficult. To reduce the speed impact of this their proxy maintains a cache of certificates rather than generating new ones for each request. No doubt other businesses in that and other sensitive arenas do the same thing.
Did he know nothing about being evil?
Never let them catch you monologuing!
IMO that sort of mix would be pretty healthy. Safer than any one with a big advantage (that one would be able to cause the sort of hassle that IE6 has caused) or there only being two major players (with three, one can go through bad spot, including dying completely, without necessarily creating a situation where one of the others ends up with 60%+ market share).
Regarding your dialup provider: assuming you are dial-up due simply to nothing else being available in your area (rather than for cost reasons) and you have a few $/month spare you could rent a cheap VPS somewhere, install your own proxy software like http://ziproxy.sourceforge.net/, and use that instead of the ISP's setup. That should do image recompression in a way that is not browser specific, apply compression to textual content (html, css, scripts) that doesn't have it already, and so on. If your ISP does something to make this impossible (perhaps their proxy is transparent and so difficult to avoid) you might need to setup a VPN between you and your proxy (using OpenVPN, or perhaps just a SSH tunnel) to work around such limitations.
See my above reply... I don't disagree with you, nor does it sound like you significantly disagree with me.
Group in your #1 is not so very small, and they are the ones that will freak out and tell everyone on Facebook that your site hacked their computer when they get the security popup...
Aye. Loud-but-clueless people can be very difficult to ignore, much as we might like to try!
In another year or two hopefully everyone will be using SNI...
Or we might all be using IPv6 in which case the point is moot as practically every site name can have its own routable IP address anyway. Though SNI support being common enough that we can just ignore browsers without it is more likely to happen first (given that IE on XP is the only major problem in that area).
I know replying to my own post is often considered bad form, but I've spotted a sentence I failed to finish typing...
"then they are doomed to try do things." should be something like "then they are doomed to try do things that do not offer the security they think while diminishing the strength of existing protections or at least further confusing public thought about them."
He says 'it's still better than plain-text!' and you say 'Unfortunately that is not the case.' because you're been trained that it's not the case.
And then you are forced to actually justify why it's not the case, and end up say 'So it is a bit better than plain text'.
So, basically, you admit he's right, but you've been told over and over he's wrong, so you somehow think he must be wrong, even though you just admitted he was right.
No. No. And No. I said it is "a bit harder", in that an attacker needs to make slightly more effort to perform a MitM attack, but that this is not enough as such little extra effort is not much more difficult to automate than the session stealing trick used by the recent "plain http isn't safe even if you use https for login" demonstrations. I pointed out that it is in fact a bit harder otherwise I would have looked like the mindless drone you take me for in your misunderstanding, and described why his "a bit harder" simply isn't enough.
There is no justification for warning people about unsigned encrypted if you're going to let them do plaintext without a warning. Anyone who thinks about this has to admit that. Even people like you who can't admit it...have to admit it.
No, we do not have to. No we won't.
There is justification for warning people about certificates without full trust chains, and that is that using such certificates does not protect you from everything that certificates with full trust chains protect you from: namely proxy-based and/or arp poisoning based man-in-the-middle inspection/injection vectors.
Letting people use something called https that looks like https and acts like https without actually offering the same protection of proper https (i.e. without offering protection against the proxy based and/or arp poisoning based MitM attacks a self-signed certificate attacks that certificates with properly signed trust paths protect you from but self-signed certificates do not) will only lead people into a false sense of security. The warning exists because a self-signed certificate does not give the guarantees that one with a valid trust path gives, and it is right to raise the warning because this potentially renders the assurance offere by https completely invalid.
If you are in a situation where you do not control or otherwise explicitly trust every host on the route between you and the server and every host on the same network segments as all those hosts (including any within 100m if you are using public wireless), then browsing with https with a self-signed certificate is not significantly more secure than browsing with plain http. And there are very very few situations where you can guarantee that level of trust of the server and all the nodes and network legs between you and it can be justified. Claiming that the connection is secure in these cases by showing a little padlock and not warning the user that they do not have the full protection https could offer would be wrong.
but if you care enough about the content to use HTTPS in the first place then "a bit better" is not enough.
What a dumb statement. If you care enough about content to used signed HTTPS, then obviously unsigned HTTPS is not enough.
Of course, NO ONE IS TALKING ABOUT LOWERING THE SECURITY OF ANY SITE. The question was explicitly talking about currently-plaintext sites. As is the article. There's no any possible way to misunderstand this.
What a dumb response to my statement (sorry, I just did that to illustrate how invalid an ad hominem attack like yours is in these discussions). I'm not talking about lowering the security of implementations that already correctly using https, nowhere do I mention that I'm talking about lowering the security of existing https use. What I state quote clearly is that
Definitely still commendable. Dropping to script is a much better option than wigging out and completely panicking, perhaps making the situation worse.
1) Granny's not going to pay $100s per year for her blog.
Granny's block doesn't really need encrypting under its own name though (which is a fault in the question, rather than your answer). For reading it is no doubt public information that needs no protection. For protecting logged in sessions when she is making updates she is probably using a service like Blogger anyway and can edit using their domain even if she has her own domain name associated with the block for readers to access it through. Chances are she doesn't have her own domain anyway and her blog is themusingsofagranny.someblogsite.com or someblogsite.com/themusingsofagranny so her site can use the blog provider's (wildcard) certificate anyway. In no way should Granny need to pay for a cert for this. Anyway, startssl's free certs are accepted by the majority of browsers these days (http://en.wikipedia.org/wiki/Startssl#StartSSL).
2) Processing overhead. Security comes at the cost of speed.
The processing overhead is very small on modern CPUs - before the CPU becomes a significant bottleneck in this regard other parts of your infrastructure will have long since become a problem. There is extra latency in the initial negotiations, but that is only per session and should not be a problem for a decent web server, a decent client, and all but the slowest of connections. Content caching (or lack thereof) could be an issue, but proper use of cache-control headers will mitigate this for the most part (not something Granny needs to worry about - a good blog software setup should handle it without her even knowing the issue might exist).
1) SSL certificates are not free
Not quite correct: the CA cert used by startssl to sign their free keys is trusted by most browsers these days (see http://en.wikipedia.org/wiki/Startssl#StartSSL). Though you may find some XP+IE installs don't trust these certificates if the "root certs update" patches are not installed (these are not marked as critical or important in Windows Update IIRC).
2) SSL key exchanges are horribly expensive compared with serving a web page
The full certificate and key exchange only has to happen once per session so is not all that expensive overall. Even caching issues can be pretty much mitigated by proper use of cache-control headers for static objects (styles, images, scripts) and/or public content (html that contains no user specific information).
3) Right now EVERY web site would require a unique IP address
Only if you have to support users using XP+IE. Everything else of note (including IE on Vista/7 and other major browsers on everything including XP) supports Server Name Indication (https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication#Support) which removes the need for a 1-to-1 mapping of names to addresses for SSL purposes.
------------
The real reasons for lack of HTTPS on most sites/apps are:
1. Users stuck with XP+IE as their only browsing option (either due to ignorance of other options or because they operate in a locked-down environment that is out of date in that respect) and sites not wanting to alienate this (now very small) portion of the market
2. Mis-information and/or lack of knowledge of recent changes in the market on the part of developers and site/server managers.
3. Despite most web servers having supported SNI for a while, some common "web hosting control panel" software is not yet aware of it
4. A lot of content (i.e. truly public information) really doesn't need encrypting at all
I would love to see CACert in the default CA databases widely, that would help a lot.
The root certificate used by startssl to sign their free certificates is in most OSs' default list of trusted root certificates these days (http://en.wikipedia.org/wiki/Startssl#StartSSL). It might not be totally reliable for Windows users (for IE on XP at least it depends on them having the "root certificates update" patches installed, and they are not marked as critical or important so may not be installed everywhere), but seems to be an increasingly practical option as XP+IE market share continues to fall.
This is addressed using Server Name Indication (https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication) - unfortunately this is not supported by Internet Explorer when running on Windows XP.
If you are happy to potentially exclude that chunk of browsers (i.e. tell then to upgrade to Firefox/Chrome/what-ever for free, upgrade to Vista/7 at cost, just put up with the certificate warnings, or just go away) then the shared IP address issue is a solved problem.
I understand that a self-signed certificate is vulnerable to MitM... however, it's still better than plain-text!
Unfortunately that is not the case. If you are browsing on an untrusted network (free wireless for instance) a transparent proxy could be MitMing the certificate process be cause anyone can "self sign" a certificate for any resource name. That nefarious proxy could decrypt the content and re-encrypt it using keys for the cert it self-signed, and inspect & log the content on the way through. This could also be done by other users of the network (not just the network itself) if done in tandem with some sort of arp spoofing attack or similar which redirects your traffic to a proxy outside the normal routing path. So it is a bit better than plain text (intercepting the content is a bit harder), but if you care enough about the content to use HTTPS in the first place then "a bit better" is not enough.
SSH is a perfect example. When you first connect via SSH, you confirm that you trust the certificate. Your client then remembers the certificate for future use. Why doesn't web technology do this?!?
This relies on you always using the same machine(s) otherwise you constantly have to accept the server certificate (via acknowledging its fingerprint is correct). Unless you actually check that the fingerprint is correct this doesn't protect you from a MitM attack at all if you are accessing the service for the first time (or from a place you've not accessed it from before so don;t have the cert stored in your known_hosts file), so it wouldn't help the general public to whom you have no efficient and secure way to transmit the correct fingerprint to check the one presented to them against. What the SSH method does protect you from (in the case when you didn't properly verify the cert on initial connection) is when the certificate changes - i.e. it stops you connecting to a host that starts handing out a different certificate (or a host that is pretending to be that host so does not have the right private key) until you have verify that the change is legitimate.
Instead, when you self-sign a cert, browsers throw a hissy fit and shows a huge warning.
The SSH model would not work for HTTPS on public services (heck, the SSH model doesn't work for SSH quite the way many people assume it does!), and self-signed certificates have the proxy problem - this is why the warning exists. You can get free certs that are trusted by the vast majority of browsers, see http://en.wikipedia.org/wiki/Startssl#StartSSL for information and links to the one source I know of (to my knowledge no other free CAs like cacert yet have that level of acceptedness). You have to renew these once per year but that really is no massive hardship.
The things holding back the use of HTTPS for small services aren't the cost (basic certs can be bought very cheaply, often free, these days), the CPU hit (even in overcrowded VPS hosts, a modern CPU doing that work is not going to be one of the significant bottlenecks): they are
1. people still using Internet Explorer under Windows XP (so people running web services don't want to use SNI which is needed for SSL to work when you don't have a dedicated IP address per service name that needs a certificate)
2. a bit of ignorance on the part of the service providers and developers
3. potential caching issues which can cause extra load on the servers (but that would not be solved by the SSH-like solution on its own) though this can be mitigated by correctly marking static content with relevant cache-control headers (see http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https for some relevant discussion and links to more detail)
Isn't SSL done on a per domain name basis?
No. But yes. Well, probably not quite yet.
No: The way HTTPS works when the "recent" SNI feature is not available is that the TLS stream is created (including certificates being negotiated and verified) before any hostname information is transferred. This means that you can only have one valid certificate per publicly addressable IP address without SNI.
But yes: With SNI (see http://en.wikipedia.org/wiki/Server_Name_Indication for info) the hostname is sent earlier, so the server can lookup the right certificate for that name and send it instead of relying on a 1-to-1 mapping between IP addresses and service names.
Well, probably not quite yet: Unfortunately SNI is not completely supported by all common user agents, particularly any version of Internet Explorer running on Windows XP, so whether you can justify using the feature right now depends a lot on who your target audience are. If you don't have any users browsing your content/app with XP+IE or you don't mind telling such users to upgrade to FF/Chrome/other, upgrade Windows, or just put up with the certificate warnings, then using SNI will work for you. You run the risk of sending XP+IE users away though, which might not be acceptable if your bottom line relies on getting as much traffic as possible through your doors.
If your site doesn't expect me to login, register, provide any content or interact with it in any way that is not completely passive, then that is perfectly fine.
Otherwise: why should I bother interacting with your site in a less passive manner than simple browsing, if you can't be bothered to enable SSL? Enabling SSL is not difficult, does not generally cause a massive amount of extra load on modern systems (if your site is relatively dynamic then your scripting language and database will be much much more significant bottlenecks on a well designed site), and is not expensive these days (cheap SSL certs are now actually cheap and there are a number of free-for-a-year offers to be found at the moment).
Why should I do X so you can Y can work both ways.
I'd say security updates and new features and better support for more hardware. I mean, would you keep running Debian 2.2 on your desktop, which are both released about the same time?
No, but then there has been a "no need to completely reinstall everything" upgrade path all the way from Debian 2.2 and the latest stable release - this is one of the reasons my home boxes will remain on XP for a while yet. The hassle (i.e. cost) of producing and testing a new build is wy many big businesses will be running XP for at least a year more if not longer. Also for me as a home user, why would I spend £100 on a copy of Windows 7 Pro to replace my XP install when I could spend that money on something else that will actually give me a benefit worth spending the money on?
Regarding security updates: yes they would be the key reason to update. XP is set to get them until April 2014 - so if I've not upgraded or switched completely to something else by then I'll upgrade some time before the end of 2013. This is the main reason business users will upgrade/switch, and probably at about the same time too.
Features? I'm not aware of any that I'd pay the money (and time reinstalling) for. Yes there might be some things in Windows 7 that I'd like, but not so much that I'd pay for them. DX10/11? DX9 is working for me right now, and any game that I might otherwise pay for that dares not support XP simply relegates itself to being something I might buy (at a bargain price compared to the price soon after release) in two years time when I have switched from XP. IE9? Much as I dislike IE6/7/8 I can just use Firefox instead of paying to be able to use IE9 without my preferred plugins. And so on.
While IE use has fallen drastically in the last year or two, that 9% figure is going to include quite a bit of audience bias. Unfortunately for those of us who have to support IE professionally the amount of people using it in some audiences is much higher, and an irritating percentage of those populations will be using ancient versions for some time to come. One of our banking clients (one of the largest in the UK) is planning to roll out IE8 "some time this year". The rest of out clients (including others in the "largest in the UK" category are still IE6 only on company desktop and laptop builds.
IE9 would be good news (afterall, it is far more compliant then any version of IE that has gone before) if people using older IE versions switched to it. Unfortunately this is not going to happen as many people who are still using IE for day-to-day browsing either don't care enough to upgrade (hence aren't already using FF/Chrome/Opera/other, though if IE is pushed as an "important" update MS will catch most if the Vista/7 users automagically) and/or simply can't because IE9 will not run on XP.