I have a sub-domain which has a catch-all account. Every form I will out gets a different address on that subdomain (usually with something in the name that identified the entity I gave the address to and why, with something random so they can't claim a spammer just guessed the address - something like slashdot4808signup@sub.domain.tld). Then if someone flogs on my address or I otherwise get crap I don't want down it after asking to be taken off their lists I can just set that address to forward to/dev/null. Of course that means I'm probably getting a pile of junk delivered each day that just gets discarded, but the volume is not high enough that it even starts to figure on any cost radar. My main addresses have managed to leak out over time, and my primary address is forename@surname.net so it sees a lot of junk sent to commonname@anydomain.tld, so my system isn't perfect. But it did keep junk to a manageable level even before the recent drop in volume (which made me run tests to make sure my mail server was still working fine for accepting mail!).
Say somebody is behind an ISP that fails to provide its own reliable SMTP server to its home subscribers. He can't run his own mail server because it'd be confused with a spam zombie. Nor can he switch to a different ISP without either moving or lowering his monthly transfer cap by a factor of ten. Which mail server do you recommend for this person?
Such an ISP may not provide a static IP address and if they do may not allow the name associated with it via rDNS to be set, so some mail hosts will reject mail from sources hooked up to that ISP anyway (because the PTR record makes the address look dynamic as the name will likely be something like 123.123.123.123.someisp.tld where 123.123.123.123 is the same as the address, or there may be no name set at all). While such a rule is usually not given a high weighting in rule+weight based spam scanning, it is often there with a score that will increase the chance of false positives against you if your mail server is talking from such an address).
One way around this, other than switching ISP which is not always practical (or even possible) or hosting the whole mail server elsewhere, is to use a VPN or tunnel to send the mail via another host where you do have unfettered ability to send stuff via SMTP and have control of the address-to-name mapping (or at least the address(es) have non-dynamic-address looking names). A cheap VPS will do, barely any resources would be needed. Though with really cheap hosts you will have to contend with them maybe being blacklisted due to spammers using their services in the recent past (usually by hacking the account of some fool who didn't care enough about the 2$/month VPS to patch and otherwise secure it properly).
If it isn't officially supported, who do they turn to when it fails in the test environment, or works itself but somehow manages to upset an unrelated policy? Should they fix it themselves? Wait for a fix that might be a while coming and delay rolling out a security update that might be significant to the safety of their users?
Teams managing the desktop builds for companies of any significant size are unlikely to touch anything that doesn't come with some promise of support (at very least some form, preferably formal, of SLA on responses to installation problems).
While a valid complaint to some extent, that is not really relevant to the current discussion regarding business use, because unless an add-on is needed for the company's use of the browser (unlikely) it not working when the next security update version rolls out won't affect people's ability to do their work.
I was under the impression this is not officially supported, just provided as a convenience, so no network manager/operator or desktop build manager (who ever is responsible for that sort of thing in a given company/group) will touch it.
Why can't I just have a D-H exchange and be done with it?
That is what you have with a self-signed certificate. DH key exchange ensures that communication between A and B can not be read by E in the middle without needing to have a pre-determined key (i.e. it solves the distribution part of the key distribution problem), but it offers no assurance as to the identity of either party which is the other half of what LTS is intended to provide. So if E is in the middle as the handshake starts that person can mediate by setting keys between A & E and E & B without either of A or B knowing that they are not talking to who they think they are talking to. E can then read everything as it passes through.
That is why certificates are needed at all. Certificates have nothing to do with the encryption used to protect the data in transit, they are there to assure the sender that the data is going to the right entity - that you are in fact you (or, more precisely, that a given server is in fact running the requested service on your behalf at your request).
Obviously it's not a lot of money, but I see no reason to pay $10 yearly to some random company for encryption that I can do myself.
But you can't do the identity verification yourself. Well, you can, but when you say you are genuinely who you say you are, how does anyone know that you are not someone pretending to be who you say you are?
Furthermore,
I see no reason to trust startssl.com any more than my own site, and I don't see why any of my (admittedly very few, but that's irrelevant) users should either.
That is exactly what it comes down to. If you don't trust startssl remove their CA cert from your browser's list. Conversely why should anyone else trust you to sign certificates? Within a small group there is obviously some trust garnered by some means, all you have to do is ask that small group to add a CA cert that you create to their browsers (though please explain to them that this would allow you, or someone who manages to hack you and get hold of the CA cert's private key, to sign a cert for any name - so that they are making an informed decision when adding your CA cert to their trusted list), but for public consumption this simply will not work (what reason would a member of the public who had never encountered you before have for trusting you to sign certificates indicating the authenticity of someone's identity?).
There are issues of trust in the current system, mainly because we end up trusting one or two entities (MS, Mozilla, Google,...) to decide who else we trust by default by virtue of which CA certs are accepted by default (I've removed the CA of China's CNNIC from my browser's trust lists for instance, and if I looked into it more deeply there may be others I'd consider removing) - the "web of trust" talked about a lot in the early 90s is essentially a "tree of trust". There have been many suggestions about how this could be improved with a peer-to-peer based system, but thus far no one has come up with a trust distribution scheme convincing enough to replace what we have now.
Dropping the identification half of what TLS provides (by accepting self-signed certs too easily, or removing the need for certs at all) is not the answer. That would remove (or render impotent) the identity assurance for those who do care about it for their service and I for one don't want to lose that just so you can have what you want your way.
Perhaps there is a need for encryption-only "casual snooping proof" transport but if there is it should be implemented as something else and not by neutering part of what TLS provides. If you want it so badly, and you can find enough other people that do, perhaps you could design/implement/fund a proof-of-concept system that you can demonstrate to get the rest of the Internet on-board.
The above is all I want. To summarize: Signed TLS is terrific. Self-signed TLS is less so. Plain http is terrible. My entire complaint is that browsers are currently not reflecting this. They are reversing the last two.
That is not how I (or peple in the security community) see it.
* http is fine for things that need no transport security, if your service should have transport level security then do not provide the service over http
* https with a properly signed certificate is for things that do need transport security
* self signed certificates are intended for testing only. If they are uses in live environments then users must be warned about the possible dangers of accepting one. If you provide your users with a self-signed certificate you should also provide them with a method of verifying that certificate (for instance with a copy of the fingerprint distributed by some other secure method.
Modern browsers are correctly reflecting this view of things (older browsers (pre 2000 IIRC) didn't, which you probably remember).
If you maintain that plain http is
equal or better than self-signed TLS then we have nothing more to disuss.
I do not maintain, nor have I stated at all, the plain http is equal or better than self-signed TLS. I have said that self-signed TLS, if accepted without stark enough warning that the certificate needs to be properly verified by the user because the browser was unable to do so with the information it has previously been given (the trusted CAs list), gives users a false sense of security. They will likely think they are as protected as with TLS with a valid trust chain, but they won't be.
If your service needs or recommends transport level security then why not simply not provide a plain channel as an alternative, redirecting any initial requests over http to the https service, and people will not choose http over https because they will not have the option to. Or indeed pony up $9.99/yr for a cert from a commonly trusted CA. Or wait for https://www.startssl.com/?app=39 to fix their problems (and release an honest account of what happened and why and what is in place to remove the risk of repetition) and get one for free. Giving users another OK button to be trained to click without thinking is not the answer.
Just in case anyone cares, I've just given Opera Mobile a spin, and it seems to work pretty well at QVGA resolution. Firefox may have just lost the chance to be what replaces the built-in browser on my poor little smartphone.
Here is a typical and realistic scenario instead: You connect to my site, and being the paranoid type you prefer https.
You get a self-signed cert. Would you grumpily accept it or would you go to http? I'd imagine the former.
Neither. If I didn't care who might snoop what I'm about to read/post I might go with either http of let the self-signed in (though just this once, not as a permanent exception), though obviously not for the webmail example you quoted above as that would involve a username+password and other content I might care about. If I did care about the info and if (and only if) I was expecting a self-signed certificate and had a fingerprint from a secure source to check against or some other way to verify the cert, then I might let the cert stand. I might even add a permanent exception. If I did care about the info and didn't have a way to verify the cert I would be on my way. If I had paid anything for your service I would consider it unfit for purpose and be quite irritated.
Next, you bring your laptop to a Starbucks, where for all you know some bastard has stuck a hub and plug computer on the router when it was all installed and the proprietor has no idea. You want to use my site again. Would you use http or https?
In the unlikely event that I had previously added a permanent (until expiry) exception for the current certificate https would not be an issue. If I didn't care about what I'm about to post (including any auth credentials and session keys) or read then either https/http would do. If I did care about the info/credentials in any way and I didn't have an exception set (or the site didn't have a properly signed cert) then I would simply not use the service on that occasion. And if your service is inconvenient to me for this reason I would make a point of finding an alternative.
Consider that with http you are guaranteed to be sniffed without even knowing it.
Actually not, as I would not let anything I cared about (authentication credentials, mail, even just session keys (sites that take logins via http then switch back to http really are showing they don't have the first clue) and so forth) go over http and no one should be encouraged to do otherwise. It shouldn't be a question of "secure isn't working right, I'll use insecure" it should be "secure isn't working right, oh well I'll have to do something else".
Actually not for another reason too: I never use public wireless without all my traffic going through a VPN (though that is not relevant to this discussion as most people-on-the-street would not have, not care to have, such an arrangement).
This scenario faces me all the time. So I'm quite happy with the self signed cert. If I've missed something big, please do tell
I've done tell. More than once. You've asked for brevity so I'll not repeat myself again.
I'm intrigued as to how you face this situation regularly.
Unless you are talking about certificates that you have signed yourself or properly verified against a fingerprint obtained by other, secure, means rather than just clicking OK then fine. But otherwise you should not be accepting self-signed certificates for any https communication that you care about and you certainly shouldn't encourage other people to do so because even if it is OK once it might not be later and after you've shown some people how to accept one self-signed certificate many will just accept any they get from anywhere in future. To top it off, they'll blame you if anything untoward does happen to them after they accepted a self-signed cert from what appeared to be their bank - because you told them accepting self-signed certificates was fine (I'm currently having memories of trying to explain to a friend why that keylogging search toolbar should not have been allowed in and not getting through to him that "Peter saying it was OK when we installed t
The microwave one is actually due to a real case. It was not uncommon to put a small animal in a draw at the cool side of a recently used big AGA oven to warm the animal up of dry it off. Some old dear tried this with a microwave, not knowing that even though it had the word "oven" associated with it it was not at all the same thing as her old aga, with predictable results. I don't know if she won or lost her case, but since them microwaves have carried that warning just in case someone else tries the same thing.
You aren't just getting less CPU and GPU power and screen size/resolution though. You are getting a smaller lighter device with (in many, but not all, cases) better battery life.
My current netbook (N550, 1Gb RAM, 250Gb HDD) is about perfectly capable for what I do on the move (basic web browsing & email via tethering to my phone or using wireless where available, a little development, documents/spreadsheets in openoffice, some MP3s and occasionally video) while being significantly more convenient to carry than a larger device and still having a usable keyboard unlike those touch-screen things (almost perfect because I may have been better to go with the N450 based model for the better battery life claim, and I might open her up and put in an SSD in place of the spinning disc at some point in the future, but those are nit-picks rather than problems).
I suspect there is large enough market for netbooks in people like me for who the format is closer to ideal than either a bigger laptop or a tablet, for the market to survive for a while yet.
If you need/want a bigger screen or more power, and don't mind the extra size and weight (or don't mind the extra cost for one that doesn't weight a chunk more than a netbook - there are some surprisingly feather-light models at the more expensive end of the market), then yes a netbook is a bad choice for you. You probably wouldn't need to spend as much as that extra $100 either, especially if you keep an eye out for special offers. My old man is considering a 15"/3Gb/250Gb model with a reasonable CPU and GPU that is only £15 more than my netbook cost. If you are happy with a lower umpth (but still significantly faster than an Atom) CPU & GPU, 1Gb or 2Gb RAM and a 160Gb drive then there are models that are cheaper still. My netbook wouldn't be great for him, but for me the price/performance/convenience/utility balance is excellent and given how many I see in use on the train when I travel I'm guessing there are plenty of other people who also find then the best choice from what the current market offers.
tl;dr: netbooks are the best choice for a lot of people. If you are not one of those people then yes you will be better served by the full-size laptop or tablet markets. Strokes for folks and all that.
Since browsers make such a fuss about self-signed certs, all webserver installations default to plain http. They could generate a self-signed cert on install and serve https by default (redirecting http to https), but this is unworkable thanks to browsers treating self-signed worse than unencrypted.
Web servers do not default to HTTPS because self signed certs are not (rightly) convenient to use in the wild, until about five or six years ago (before people realised how easily properly certificated sites could be MitMed that way if you manage a DNS poisoning attack first) browsers didn't make the big fuss and HTTPS-with-self-signed-certs wasn't done by default then. The default to HTTP because HTTPS is not needed for most content. Back in the day when I were nowt but knee 'igh t' grass'opper the extra processing was expensive CPU wise, and now even though CPUs are at the point where the extra computation server-side is neither here nor there (as a modern CPU can saturate any line you have it throw content down, if you can afford a line faster than your current CPUs can cope with you can afford better CUPs too) I would not recommend HTTPS for all content. It adds latency (Google have done some good work reducing this, but that hasn't been implemented elsewhere much that I know of) which while insignificant with a fast round-trip time is quite noticeable if you are a mobile or satellite link, it removes the possibility of transport level compression (which can be a real boon if on that mobile link in a an area where the best signal you can get is basic GPRS), it removes a lot of caching potential (this will increase the load on servers and their bandwidth), and so forth.
Also your automatic self-signed certificates would have no revocation method (as their nature makes this impossible to setup in a way that isn't easily DoSed) so if they are set to not expire for 10 years means that if your certificate is somehow compromised the black-hats have a valid certificate (that your users have told their browsers to trust) that they can potentially use for some time to come. If the self-signed certificates have a decent expiry time (and it would need to be lower than the year common for trusted-CA-signed certs to account for the can't-be-revoked problem) then your users are going to get the honking "certificate changed! you could be under attack!" message every time your certificate needs to roll over. (though one caveat there is that I don't think revocation is properly implemented in many clients as it currently stands anyway...)
Thanks to this, I can sniff my LAN and haul in gobs of login/password combination (like from slashdot.org, which doesn't support https), since the vast majority of websites use plain http since it takes an effort to use https.
If you are going to sniff traffic on your LAN then you might well try MitM self-signed SSL sites. If I don't trust your network for sending particular content over plain HTTP then I don't trust your network for sending the same content via a self-signed site. If I don't care about that traffic going via self-signed HTTPS (unless I've personally verified the certificate by other means) then I'm probably happy for it to go over plain HTTP too.
I don't have to get frustrated by the encrypted self-signed connections that I can't even MitM, because invariably they've already used them previously outside my LAN and so any MitM attempt I try will throw up huge screaming warnings in the browser.
Only if they are using their own machine on your LAN, or are using the same machine they've always used (not switching machine or browser without transferring certificate stores), or not using the site for the first time. While there are other reasons to distrust machines that aren't your own (physical key loggers and such) that doesn't mean we should ignore the self-signed-cert problem because there are other ways to capture the data.
On thing you don't often see mentioned is how well the UIs of the browsers work with very low resolution screens. There are a lot of Android devices out there with QVGA screens and Firefox's method of managing multiple open pages does not work on these devices (with more than two tabs open there is no easy way to get to the page you've selected from the thumbnails, and there is no fallback akin to the "open windows" list that the built-in browser users). It seems to require a display width of at least 480 pixels which QVGA does not have in either orientation.
Obviously you are never going to do an awful lot on a QVGA display so I can understand it not being a priority for the developers, but I find my phone surprisingly useful for reading some of the morning's news when I'm on a bus or train and there are things I might like to have FF on my poor little phone for. There are many people out there with such low-res devices so it would be nice for the developers to at least do cursory tests on them so they can state in the system requirements "may not be entirely usable on a display less than 480 pixels wide".
I did update to Firefox 4 just yesterday on one of my main machines...(well a couple of days ago, if I'm more honest)
I think I wish I'd stayed with 3.6.x for now, skipped 4 and upgraded to 5 when the early adoptors had finished getting scalped for the pioneering spirit. In fact I might uninstall v4 tomorrow when I get to the office and put 3.6 back on.
This could be great for IE. People may start moving to it from FF and Chrome as they can install a major version and get security updates for it for some time (without needed to update to the latest major version if they aren't quite ready yet for what-ever reason).
The MitM vulnerability is only there the first time you connect to a self-signed certificate site. After that you're fine.
Which is why Firefox's behaviour is correct. It can not verify the certificate against any of the CA certs it has been told to trust first time it see it, so it warns you that it has no idea if the cert is valid or it isn't and you are about to connect to EvilCorp pretending to be GoodieTwoShoes Inc. You can then inspect the certificate and confirm it is genuine using information gleaned from a known secure source and add a permanent exception for it so you won't be bothered when connecting to that site in future.
Not accepting self-signed certificates automatically is not anything to do with protecting against an MitM affecting a site with a self-signed cert - it is about protecting sites with properly signed certs (see below).
With plain http, you are vulnerable every time you connect to the site. They don't even need MitM; they can just sniff the session.
This is absolutely terrible.
Correct, but accepting self-signed certificates without warning is even worse because it allows a MitM to pretend to be a site with a properly signed cert on first connection and the user will never know. If your browser connects to https://securebanking.ltd/ and gets a self-signed certificate from a MitM instead of the one the site actually has signed by a "trusted" CA, how will it know the difference between this malicious self-signed certificate and a "genuine" new one that the site has installed? You could suggest that the browser warns when a certificate changes (or when its type changes from "verifiable using trusted CA public keys" to not), but that would still leave sites with properly signed certificates vulnerable to MitM attacks on first connection (and once a malicious self-signed cert is connected, every connection after that). I for one would much rather keep what trust is enabled by a properly signed certificate rather than lose that just because the checks and warnings are inconvenient for sites that want to self-sign.
Folks like me who run small sites use self-signed certs all the time because I don't want to pay the extortion fees of the CA keepers, who seem to dole out certificates without really checking anyway.
Folks like you could (well, you can't at the moment as they are down due to a security breach, but that is a different discussion!) use the free certs from startssl.com which are accepted by almost all common browsers (the exception being a small proportion of the people that use IE6/7/8 under Windows XP (those that have no installed the root cert update patches from Windows Update, which are present in Vista+ by default)). Or you could get a cert for $9.99 from a number of places (or slightly cheaper by abusing certain "free SSL cert with a new domain name" offers). Is $9.99/yr really that extortionate to protect the information being read from or submitted to your services?!
If your audience is so small that you $9.99 or the minor hassle of registering with startssl and using their control panel to generate a cert is too much in exchange for protecting them/you with a trusted signed certificate, then your audience is small enough that you can ask them all to install your CA cert into their trusted list and then anything you sign with it is fine.
With regard to "don't check anything anyway": they at very least verify that the person requesting the certificate has access to one of certain admin accounts associated with the domain in question (for higher assurance certs other checks are made, though as we are discussing the difference between cheap/free properly signed certs and self-signed ones higher assurance certs and the checks that they require are probably not relevant).
Not to be too personal....most of the nonsense is really in the SSL model as used (like trusting people you have no reason to trust) and browsers by extension implementing that messed up model.
So your argument is essentially that as the browser's trust by default a number of people you have no particular reason to trust (the current holders of generally accepted CA certs), we should just let go and trust everybody in the whole world? The trust model might be a bit broken, but the answer is not to break it completely and just give up on it without having a suitable replacement.
Whereas a self-signed certificate does not automatically make you vulnerable to an MITM. It depends entirely, whether the fingerprint of the presented cert is distributed through some other, out-of-band, channel. In fact, it can even be more secure if you use it right.
You seem to be proposing the model used by SSH. This falls down on the key exchange issue though. While the browser can verify if the fingerprint of the certificate changed since last time I used the site and warn me that the certificate may be fake as the fingerprint does not match the recorded on, how does that protect me first time I visit the site? There is no recorded fingerprint for it to compare against unless I've obtained one from some other secure source, so we need to setup some trusted secure source for the initial fingerprints and we need a way to verify that can be trusted too.
They will click on whatever it takes to get to the page! Even the wrong one.
Sod them then. If they will ignore every warning, fail to consider any concern we raise, and so on, then there is nothing we can do to help them. Let them be their own worst enemy.
But I don't ignore warnings, I don't say yes to any old thing just to get access to some bit of porn or celebrity gossip, and neither do other sensible people (even non-technical people). Why should we lessen our security, or make us make effort to manually verify each certificate by some other means, in order to remove a warning that the fools ignore anyway? Give them the warning and let them ignore it if they wish, and I'll take what action I feel appropriate (ignoring the warning if, for instance, I signed the cert or moving on elsewhere if I choose not to trust it).
In Sum: SSL, as you presented it so well, is a complete failure and needs to be scrapped for some different model.
If someone has a better model, and there are problems with the current model as implemented, then they should propose it as a new standard, or develop and demonstrate it themselves and perhaps make licensing money out of the idea. Trusted key/fingerprint exchange is a very difficult nut to crack outside of controlled systems (i.e. on public networks) though, so good luck solving that one. If someone does come up with a new method that genuinely solves the problems of the existing methods without introducing new nasties, then fame (academic fame at least, though perhaps not the "and fortune" sort) awaits them.
Suggesting "the warning messages are inconvenient, remove them" is not proposing a new model. It is removing useful features from the old one in order to remove something you find irritating about the old one.
And if you have a self-signed certificate, you fail with an F no matter how good everything else is.
Because with a self-signed certificate you are vulnerable to MiTM attacks.
So once again it's a site implying that unencrypted plain http is somehow better than an TLS connection that happens to be using an unsigned certificate.
A self-signed certificate gives a false sense of security, so plain http is better. Here is the breakdown:
* Proper signed certificate with verifiable trust chain: protects against active MiTM attacks and passive eavesdropping so the user has all the protection that HTTPS can offer
* Self-signed certificate: will protect from casual eavesdropping but does not protect against MiTM attacks because a MiTM attacker can fake the cert easily
* Plain HTTP: does not claim to protect at all in that way
If your browser allowed a certificate without verifiable trust chain to pass then the user would not know any difference so would not know they were not protected from all the things that HTTPS with a proper trust chain protects them from. This would not be a GoodThing(tm)
And firefox is still raising these big scary alerts about unsigned certs encouraging people to use unencrypted http instead of https. Just goddamned brilliant.
No. The browser is encouraging sites to use properly signed certificates instead of self-signed ones, instead of trying to pretend to the user that a self-signed cert protects them in the same way a cert with verifiable trust chain does. Sites that refuse to do so are encouraging people to use http instead, not the browser. If you want to use https on your sites, then use it properly and get a proper certificate, they can be obtained at no financial cost (or, if you must have absolutely 100% browser coverage including people who have not installed certain Windows updates under XP+IE, at minimal financial cost).
It's the doorlock equivalent of raising a stink that since you don't have a triple deadbolt, just don't lock the door at all.
No. Allowing the use of a self-signed certificate instead of the hassle of getting one with a verifiable trust chain is the door-lock equivalent of letting the person who installs your doors make a cheap simple easily picked lock look like a triple deadbolt lock, so the user thinks their stuff are protected by a triple deadbolt lock when it is actually protected by something much more flimsy.
If you want to use HTTPS, use it properly (which means having a certificate signed by a CA trusted by the users' browser) or your users will be warned that you are not using it properly. If you really must self-sign in a live environment for some reason, create your own CA key+cert and have your users install that as a trusted CA in their browsers (though this won't wash for a public site (good luck getting everyone to trust you to potentially sign certs for any name!) it is often done in corporate environments).
Is this ignoring their EULA which disclaims them from the very thing you are whining about?
Most clauses like that are not enforceable. There are some rights and expectations in consumer protection law that can not be waived in small print that way.
Of course this will vary from territory to territory so what is enforceable via EULA in yours may not be in mine, and you might have different statutory rights to start with. The overall legal status of click-wrap EULAs is a big fat grey area in most places too - in many cases they are not worth the paper they are not written on.
That should be skewed by when the last unit was officially sold. Someone who bought the game 12 months ago has had considerably less time to use that part of it then someone who bought it on release day.
They have, by failure to act in setting up an alternative or allowing their users to do so without beaching the click-wrap license, deliberately made their product unfit for the purpose it was sold for.
While there should be some limits on the length of applicability of this, I don't see why they shouldn't be required to release the server code so their existing players can host it somewhere or perhaps offer a partial refund for those who are still actively playing the game.
Or they could simply be made to state, in readably sized text on the back cover of the game box and other promotional materials, that they guarantee the servers will run until a certain time (if things are taken down before then, users get a refund pro-rated from date of purchase, if they are taken down after then, then people were warned and can't complain). Then people can choose at the time of purchase whether they thing this is long enough to get their moneys worth out of the game. No need to legislate a time period: just make them promise something and hold them to what-ever the something is that they promise.
Most of the ones on the good side would be equally happy being paid to work for the other side.
Not exactly immoral, but more often than not amoral.
(which is generally their job: to ensure that things are legally correct by some technical definition of legal irrespective of wishy-washy complications like morality)
Anyone have a link to a simple test script that I could use to check the sites of our suppliers (and to verify our own server's configurations before)? None of the linked articles mention one that is readily available.
Hollywood loves your wife's tastes and is catering to them, not yours. Interesting bit on the BBC this weekend, in analysis - many films are being geared to be friendly to the Chinese audiences - Hollywood knows where the money is.
In some territories Pulp Fiction was re-edited so that all the segments followed in correct chronological order, as they didn't think the audience in those places would accept the events being told the way they were for the rest of us because their story telling traditions were far more fixed format-wise and the execs thought the disjoint style of the original edit would be too jarring for them to find interesting or enjoyable.
Not quite the same as tweaking the standard edit we all see to account for possible differences in how the average Chinese audience member takes in entertainment, but Hollywood has been tweaking films for foreign markets for many years where they think it might improve sales. This is separate from censorship, where the differing cuts are usually imposed by an official body in the given territory in order to fit to locally defined standards of what is acceptable: in this case the studios are self editing to try make more money.
Slashdot Mirror
I have a sub-domain which has a catch-all account. Every form I will out gets a different address on that subdomain (usually with something in the name that identified the entity I gave the address to and why, with something random so they can't claim a spammer just guessed the address - something like slashdot4808signup@sub.domain.tld). Then if someone flogs on my address or I otherwise get crap I don't want down it after asking to be taken off their lists I can just set that address to forward to /dev/null. Of course that means I'm probably getting a pile of junk delivered each day that just gets discarded, but the volume is not high enough that it even starts to figure on any cost radar. My main addresses have managed to leak out over time, and my primary address is forename@surname.net so it sees a lot of junk sent to commonname@anydomain.tld, so my system isn't perfect. But it did keep junk to a manageable level even before the recent drop in volume (which made me run tests to make sure my mail server was still working fine for accepting mail!).
Say somebody is behind an ISP that fails to provide its own reliable SMTP server to its home subscribers. He can't run his own mail server because it'd be confused with a spam zombie. Nor can he switch to a different ISP without either moving or lowering his monthly transfer cap by a factor of ten. Which mail server do you recommend for this person?
Such an ISP may not provide a static IP address and if they do may not allow the name associated with it via rDNS to be set, so some mail hosts will reject mail from sources hooked up to that ISP anyway (because the PTR record makes the address look dynamic as the name will likely be something like 123.123.123.123.someisp.tld where 123.123.123.123 is the same as the address, or there may be no name set at all). While such a rule is usually not given a high weighting in rule+weight based spam scanning, it is often there with a score that will increase the chance of false positives against you if your mail server is talking from such an address).
One way around this, other than switching ISP which is not always practical (or even possible) or hosting the whole mail server elsewhere, is to use a VPN or tunnel to send the mail via another host where you do have unfettered ability to send stuff via SMTP and have control of the address-to-name mapping (or at least the address(es) have non-dynamic-address looking names). A cheap VPS will do, barely any resources would be needed. Though with really cheap hosts you will have to contend with them maybe being blacklisted due to spammers using their services in the recent past (usually by hacking the account of some fool who didn't care enough about the 2$/month VPS to patch and otherwise secure it properly).
Including the one who has just had his prizes taken back. I think I see how your logic is working...
If it isn't officially supported, who do they turn to when it fails in the test environment, or works itself but somehow manages to upset an unrelated policy? Should they fix it themselves? Wait for a fix that might be a while coming and delay rolling out a security update that might be significant to the safety of their users?
Teams managing the desktop builds for companies of any significant size are unlikely to touch anything that doesn't come with some promise of support (at very least some form, preferably formal, of SLA on responses to installation problems).
release schedule that constantly breaks addons
While a valid complaint to some extent, that is not really relevant to the current discussion regarding business use, because unless an add-on is needed for the company's use of the browser (unlikely) it not working when the next security update version rolls out won't affect people's ability to do their work.
I was under the impression this is not officially supported, just provided as a convenience, so no network manager/operator or desktop build manager (who ever is responsible for that sort of thing in a given company/group) will touch it.
Why can't I just have a D-H exchange and be done with it?
That is what you have with a self-signed certificate. DH key exchange ensures that communication between A and B can not be read by E in the middle without needing to have a pre-determined key (i.e. it solves the distribution part of the key distribution problem), but it offers no assurance as to the identity of either party which is the other half of what LTS is intended to provide. So if E is in the middle as the handshake starts that person can mediate by setting keys between A & E and E & B without either of A or B knowing that they are not talking to who they think they are talking to. E can then read everything as it passes through.
That is why certificates are needed at all. Certificates have nothing to do with the encryption used to protect the data in transit, they are there to assure the sender that the data is going to the right entity - that you are in fact you (or, more precisely, that a given server is in fact running the requested service on your behalf at your request).
Obviously it's not a lot of money, but I see no reason to pay $10 yearly to some random company for encryption that I can do myself.
But you can't do the identity verification yourself. Well, you can, but when you say you are genuinely who you say you are, how does anyone know that you are not someone pretending to be who you say you are?
Furthermore, I see no reason to trust startssl.com any more than my own site, and I don't see why any of my (admittedly very few, but that's irrelevant) users should either.
That is exactly what it comes down to. If you don't trust startssl remove their CA cert from your browser's list. Conversely why should anyone else trust you to sign certificates? Within a small group there is obviously some trust garnered by some means, all you have to do is ask that small group to add a CA cert that you create to their browsers (though please explain to them that this would allow you, or someone who manages to hack you and get hold of the CA cert's private key, to sign a cert for any name - so that they are making an informed decision when adding your CA cert to their trusted list), but for public consumption this simply will not work (what reason would a member of the public who had never encountered you before have for trusting you to sign certificates indicating the authenticity of someone's identity?).
...) to decide who else we trust by default by virtue of which CA certs are accepted by default (I've removed the CA of China's CNNIC from my browser's trust lists for instance, and if I looked into it more deeply there may be others I'd consider removing) - the "web of trust" talked about a lot in the early 90s is essentially a "tree of trust". There have been many suggestions about how this could be improved with a peer-to-peer based system, but thus far no one has come up with a trust distribution scheme convincing enough to replace what we have now.
There are issues of trust in the current system, mainly because we end up trusting one or two entities (MS, Mozilla, Google,
Dropping the identification half of what TLS provides (by accepting self-signed certs too easily, or removing the need for certs at all) is not the answer. That would remove (or render impotent) the identity assurance for those who do care about it for their service and I for one don't want to lose that just so you can have what you want your way.
Perhaps there is a need for encryption-only "casual snooping proof" transport but if there is it should be implemented as something else and not by neutering part of what TLS provides. If you want it so badly, and you can find enough other people that do, perhaps you could design/implement/fund a proof-of-concept system that you can demonstrate to get the rest of the Internet on-board.
The above is all I want. To summarize:
Signed TLS is terrific.
Self-signed TLS is less so.
Plain http is terrible.
My entire complaint is that browsers are currently not reflecting this. They are reversing the last two.
That is not how I (or peple in the security community) see it.
* http is fine for things that need no transport security, if your service should have transport level security then do not provide the service over http
* https with a properly signed certificate is for things that do need transport security
* self signed certificates are intended for testing only. If they are uses in live environments then users must be warned about the possible dangers of accepting one. If you provide your users with a self-signed certificate you should also provide them with a method of verifying that certificate (for instance with a copy of the fingerprint distributed by some other secure method.
Modern browsers are correctly reflecting this view of things (older browsers (pre 2000 IIRC) didn't, which you probably remember).
If you maintain that plain http is equal or better than self-signed TLS then we have nothing more to disuss.
I do not maintain, nor have I stated at all, the plain http is equal or better than self-signed TLS. I have said that self-signed TLS, if accepted without stark enough warning that the certificate needs to be properly verified by the user because the browser was unable to do so with the information it has previously been given (the trusted CAs list), gives users a false sense of security. They will likely think they are as protected as with TLS with a valid trust chain, but they won't be.
If your service needs or recommends transport level security then why not simply not provide a plain channel as an alternative, redirecting any initial requests over http to the https service, and people will not choose http over https because they will not have the option to. Or indeed pony up $9.99/yr for a cert from a commonly trusted CA. Or wait for https://www.startssl.com/?app=39 to fix their problems (and release an honest account of what happened and why and what is in place to remove the risk of repetition) and get one for free. Giving users another OK button to be trained to click without thinking is not the answer.
Just in case anyone cares, I've just given Opera Mobile a spin, and it seems to work pretty well at QVGA resolution. Firefox may have just lost the chance to be what replaces the built-in browser on my poor little smartphone.
Here is a typical and realistic scenario instead: You connect to my site, and being the paranoid type you prefer https. You get a self-signed cert. Would you grumpily accept it or would you go to http? I'd imagine the former.
Neither. If I didn't care who might snoop what I'm about to read/post I might go with either http of let the self-signed in (though just this once, not as a permanent exception), though obviously not for the webmail example you quoted above as that would involve a username+password and other content I might care about. If I did care about the info and if (and only if) I was expecting a self-signed certificate and had a fingerprint from a secure source to check against or some other way to verify the cert, then I might let the cert stand. I might even add a permanent exception. If I did care about the info and didn't have a way to verify the cert I would be on my way. If I had paid anything for your service I would consider it unfit for purpose and be quite irritated.
Next, you bring your laptop to a Starbucks, where for all you know some bastard has stuck a hub and plug computer on the router when it was all installed and the proprietor has no idea. You want to use my site again. Would you use http or https?
In the unlikely event that I had previously added a permanent (until expiry) exception for the current certificate https would not be an issue. If I didn't care about what I'm about to post (including any auth credentials and session keys) or read then either https/http would do. If I did care about the info/credentials in any way and I didn't have an exception set (or the site didn't have a properly signed cert) then I would simply not use the service on that occasion. And if your service is inconvenient to me for this reason I would make a point of finding an alternative.
Consider that with http you are guaranteed to be sniffed without even knowing it.
Actually not, as I would not let anything I cared about (authentication credentials, mail, even just session keys (sites that take logins via http then switch back to http really are showing they don't have the first clue) and so forth) go over http and no one should be encouraged to do otherwise. It shouldn't be a question of "secure isn't working right, I'll use insecure" it should be "secure isn't working right, oh well I'll have to do something else".
Actually not for another reason too: I never use public wireless without all my traffic going through a VPN (though that is not relevant to this discussion as most people-on-the-street would not have, not care to have, such an arrangement).
This scenario faces me all the time. So I'm quite happy with the self signed cert. If I've missed something big, please do tell
I've done tell. More than once. You've asked for brevity so I'll not repeat myself again.
I'm intrigued as to how you face this situation regularly.
Unless you are talking about certificates that you have signed yourself or properly verified against a fingerprint obtained by other, secure, means rather than just clicking OK then fine. But otherwise you should not be accepting self-signed certificates for any https communication that you care about and you certainly shouldn't encourage other people to do so because even if it is OK once it might not be later and after you've shown some people how to accept one self-signed certificate many will just accept any they get from anywhere in future. To top it off, they'll blame you if anything untoward does happen to them after they accepted a self-signed cert from what appeared to be their bank - because you told them accepting self-signed certificates was fine (I'm currently having memories of trying to explain to a friend why that keylogging search toolbar should not have been allowed in and not getting through to him that "Peter saying it was OK when we installed t
The microwave one is actually due to a real case. It was not uncommon to put a small animal in a draw at the cool side of a recently used big AGA oven to warm the animal up of dry it off. Some old dear tried this with a microwave, not knowing that even though it had the word "oven" associated with it it was not at all the same thing as her old aga, with predictable results. I don't know if she won or lost her case, but since them microwaves have carried that warning just in case someone else tries the same thing.
You aren't just getting less CPU and GPU power and screen size/resolution though. You are getting a smaller lighter device with (in many, but not all, cases) better battery life.
My current netbook (N550, 1Gb RAM, 250Gb HDD) is about perfectly capable for what I do on the move (basic web browsing & email via tethering to my phone or using wireless where available, a little development, documents/spreadsheets in openoffice, some MP3s and occasionally video) while being significantly more convenient to carry than a larger device and still having a usable keyboard unlike those touch-screen things (almost perfect because I may have been better to go with the N450 based model for the better battery life claim, and I might open her up and put in an SSD in place of the spinning disc at some point in the future, but those are nit-picks rather than problems).
I suspect there is large enough market for netbooks in people like me for who the format is closer to ideal than either a bigger laptop or a tablet, for the market to survive for a while yet.
If you need/want a bigger screen or more power, and don't mind the extra size and weight (or don't mind the extra cost for one that doesn't weight a chunk more than a netbook - there are some surprisingly feather-light models at the more expensive end of the market), then yes a netbook is a bad choice for you. You probably wouldn't need to spend as much as that extra $100 either, especially if you keep an eye out for special offers. My old man is considering a 15"/3Gb/250Gb model with a reasonable CPU and GPU that is only £15 more than my netbook cost. If you are happy with a lower umpth (but still significantly faster than an Atom) CPU & GPU, 1Gb or 2Gb RAM and a 160Gb drive then there are models that are cheaper still. My netbook wouldn't be great for him, but for me the price/performance/convenience/utility balance is excellent and given how many I see in use on the train when I travel I'm guessing there are plenty of other people who also find then the best choice from what the current market offers.
tl;dr: netbooks are the best choice for a lot of people. If you are not one of those people then yes you will be better served by the full-size laptop or tablet markets. Strokes for folks and all that.
Since browsers make such a fuss about self-signed certs, all webserver installations default to plain http. They could generate a self-signed cert on install and serve https by default (redirecting http to https), but this is unworkable thanks to browsers treating self-signed worse than unencrypted.
Web servers do not default to HTTPS because self signed certs are not (rightly) convenient to use in the wild, until about five or six years ago (before people realised how easily properly certificated sites could be MitMed that way if you manage a DNS poisoning attack first) browsers didn't make the big fuss and HTTPS-with-self-signed-certs wasn't done by default then. The default to HTTP because HTTPS is not needed for most content. Back in the day when I were nowt but knee 'igh t' grass'opper the extra processing was expensive CPU wise, and now even though CPUs are at the point where the extra computation server-side is neither here nor there (as a modern CPU can saturate any line you have it throw content down, if you can afford a line faster than your current CPUs can cope with you can afford better CUPs too) I would not recommend HTTPS for all content. It adds latency (Google have done some good work reducing this, but that hasn't been implemented elsewhere much that I know of) which while insignificant with a fast round-trip time is quite noticeable if you are a mobile or satellite link, it removes the possibility of transport level compression (which can be a real boon if on that mobile link in a an area where the best signal you can get is basic GPRS), it removes a lot of caching potential (this will increase the load on servers and their bandwidth), and so forth.
Also your automatic self-signed certificates would have no revocation method (as their nature makes this impossible to setup in a way that isn't easily DoSed) so if they are set to not expire for 10 years means that if your certificate is somehow compromised the black-hats have a valid certificate (that your users have told their browsers to trust) that they can potentially use for some time to come. If the self-signed certificates have a decent expiry time (and it would need to be lower than the year common for trusted-CA-signed certs to account for the can't-be-revoked problem) then your users are going to get the honking "certificate changed! you could be under attack!" message every time your certificate needs to roll over. (though one caveat there is that I don't think revocation is properly implemented in many clients as it currently stands anyway...)
Thanks to this, I can sniff my LAN and haul in gobs of login/password combination (like from slashdot.org, which doesn't support https), since the vast majority of websites use plain http since it takes an effort to use https.
If you are going to sniff traffic on your LAN then you might well try MitM self-signed SSL sites. If I don't trust your network for sending particular content over plain HTTP then I don't trust your network for sending the same content via a self-signed site. If I don't care about that traffic going via self-signed HTTPS (unless I've personally verified the certificate by other means) then I'm probably happy for it to go over plain HTTP too.
I don't have to get frustrated by the encrypted self-signed connections that I can't even MitM, because invariably they've already used them previously outside my LAN and so any MitM attempt I try will throw up huge screaming warnings in the browser.
Only if they are using their own machine on your LAN, or are using the same machine they've always used (not switching machine or browser without transferring certificate stores), or not using the site for the first time. While there are other reasons to distrust machines that aren't your own (physical key loggers and such) that doesn't mean we should ignore the self-signed-cert problem because there are other ways to capture the data.
On thing you don't often see mentioned is how well the UIs of the browsers work with very low resolution screens. There are a lot of Android devices out there with QVGA screens and Firefox's method of managing multiple open pages does not work on these devices (with more than two tabs open there is no easy way to get to the page you've selected from the thumbnails, and there is no fallback akin to the "open windows" list that the built-in browser users). It seems to require a display width of at least 480 pixels which QVGA does not have in either orientation.
Obviously you are never going to do an awful lot on a QVGA display so I can understand it not being a priority for the developers, but I find my phone surprisingly useful for reading some of the morning's news when I'm on a bus or train and there are things I might like to have FF on my poor little phone for. There are many people out there with such low-res devices so it would be nice for the developers to at least do cursory tests on them so they can state in the system requirements "may not be entirely usable on a display less than 480 pixels wide".
I did update to Firefox 4 just yesterday on one of my main machines...(well a couple of days ago, if I'm more honest)
I think I wish I'd stayed with 3.6.x for now, skipped 4 and upgraded to 5 when the early adoptors had finished getting scalped for the pioneering spirit. In fact I might uninstall v4 tomorrow when I get to the office and put 3.6 back on.
This could be great for IE. People may start moving to it from FF and Chrome as they can install a major version and get security updates for it for some time (without needed to update to the latest major version if they aren't quite ready yet for what-ever reason).
The MitM vulnerability is only there the first time you connect to a self-signed certificate site. After that you're fine.
Which is why Firefox's behaviour is correct. It can not verify the certificate against any of the CA certs it has been told to trust first time it see it, so it warns you that it has no idea if the cert is valid or it isn't and you are about to connect to EvilCorp pretending to be GoodieTwoShoes Inc. You can then inspect the certificate and confirm it is genuine using information gleaned from a known secure source and add a permanent exception for it so you won't be bothered when connecting to that site in future.
Not accepting self-signed certificates automatically is not anything to do with protecting against an MitM affecting a site with a self-signed cert - it is about protecting sites with properly signed certs (see below).
With plain http, you are vulnerable every time you connect to the site. They don't even need MitM; they can just sniff the session. This is absolutely terrible.
Correct, but accepting self-signed certificates without warning is even worse because it allows a MitM to pretend to be a site with a properly signed cert on first connection and the user will never know. If your browser connects to https://securebanking.ltd/ and gets a self-signed certificate from a MitM instead of the one the site actually has signed by a "trusted" CA, how will it know the difference between this malicious self-signed certificate and a "genuine" new one that the site has installed? You could suggest that the browser warns when a certificate changes (or when its type changes from "verifiable using trusted CA public keys" to not), but that would still leave sites with properly signed certificates vulnerable to MitM attacks on first connection (and once a malicious self-signed cert is connected, every connection after that). I for one would much rather keep what trust is enabled by a properly signed certificate rather than lose that just because the checks and warnings are inconvenient for sites that want to self-sign.
Folks like me who run small sites use self-signed certs all the time because I don't want to pay the extortion fees of the CA keepers, who seem to dole out certificates without really checking anyway.
Folks like you could (well, you can't at the moment as they are down due to a security breach, but that is a different discussion!) use the free certs from startssl.com which are accepted by almost all common browsers (the exception being a small proportion of the people that use IE6/7/8 under Windows XP (those that have no installed the root cert update patches from Windows Update, which are present in Vista+ by default)). Or you could get a cert for $9.99 from a number of places (or slightly cheaper by abusing certain "free SSL cert with a new domain name" offers). Is $9.99/yr really that extortionate to protect the information being read from or submitted to your services?!
If your audience is so small that you $9.99 or the minor hassle of registering with startssl and using their control panel to generate a cert is too much in exchange for protecting them/you with a trusted signed certificate, then your audience is small enough that you can ask them all to install your CA cert into their trusted list and then anything you sign with it is fine.
With regard to "don't check anything anyway": they at very least verify that the person requesting the certificate has access to one of certain admin accounts associated with the domain in question (for higher assurance certs other checks are made, though as we are discussing the difference between cheap/free properly signed certs and self-signed ones higher assurance certs and the checks that they require are probably not relevant).
Self signed certs are not ideal, but they are d
Not to be too personal....most of the nonsense is really in the SSL model as used (like trusting people you have no reason to trust) and browsers by extension implementing that messed up model.
So your argument is essentially that as the browser's trust by default a number of people you have no particular reason to trust (the current holders of generally accepted CA certs), we should just let go and trust everybody in the whole world? The trust model might be a bit broken, but the answer is not to break it completely and just give up on it without having a suitable replacement.
Whereas a self-signed certificate does not automatically make you vulnerable to an MITM. It depends entirely, whether the fingerprint of the presented cert is distributed through some other, out-of-band, channel. In fact, it can even be more secure if you use it right.
You seem to be proposing the model used by SSH. This falls down on the key exchange issue though. While the browser can verify if the fingerprint of the certificate changed since last time I used the site and warn me that the certificate may be fake as the fingerprint does not match the recorded on, how does that protect me first time I visit the site? There is no recorded fingerprint for it to compare against unless I've obtained one from some other secure source, so we need to setup some trusted secure source for the initial fingerprints and we need a way to verify that can be trusted too.
They will click on whatever it takes to get to the page! Even the wrong one.
Sod them then. If they will ignore every warning, fail to consider any concern we raise, and so on, then there is nothing we can do to help them. Let them be their own worst enemy.
But I don't ignore warnings, I don't say yes to any old thing just to get access to some bit of porn or celebrity gossip, and neither do other sensible people (even non-technical people). Why should we lessen our security, or make us make effort to manually verify each certificate by some other means, in order to remove a warning that the fools ignore anyway? Give them the warning and let them ignore it if they wish, and I'll take what action I feel appropriate (ignoring the warning if, for instance, I signed the cert or moving on elsewhere if I choose not to trust it).
In Sum: SSL, as you presented it so well, is a complete failure and needs to be scrapped for some different model.
If someone has a better model, and there are problems with the current model as implemented, then they should propose it as a new standard, or develop and demonstrate it themselves and perhaps make licensing money out of the idea. Trusted key/fingerprint exchange is a very difficult nut to crack outside of controlled systems (i.e. on public networks) though, so good luck solving that one. If someone does come up with a new method that genuinely solves the problems of the existing methods without introducing new nasties, then fame (academic fame at least, though perhaps not the "and fortune" sort) awaits them.
Suggesting "the warning messages are inconvenient, remove them" is not proposing a new model. It is removing useful features from the old one in order to remove something you find irritating about the old one.
And if you have a self-signed certificate, you fail with an F no matter how good everything else is.
Because with a self-signed certificate you are vulnerable to MiTM attacks.
So once again it's a site implying that unencrypted plain http is somehow better than an TLS connection that happens to be using an unsigned certificate.
A self-signed certificate gives a false sense of security, so plain http is better. Here is the breakdown:
* Proper signed certificate with verifiable trust chain: protects against active MiTM attacks and passive eavesdropping so the user has all the protection that HTTPS can offer
* Self-signed certificate: will protect from casual eavesdropping but does not protect against MiTM attacks because a MiTM attacker can fake the cert easily
* Plain HTTP: does not claim to protect at all in that way
If your browser allowed a certificate without verifiable trust chain to pass then the user would not know any difference so would not know they were not protected from all the things that HTTPS with a proper trust chain protects them from. This would not be a GoodThing(tm)
And firefox is still raising these big scary alerts about unsigned certs encouraging people to use unencrypted http instead of https. Just goddamned brilliant.
No. The browser is encouraging sites to use properly signed certificates instead of self-signed ones, instead of trying to pretend to the user that a self-signed cert protects them in the same way a cert with verifiable trust chain does. Sites that refuse to do so are encouraging people to use http instead, not the browser. If you want to use https on your sites, then use it properly and get a proper certificate, they can be obtained at no financial cost (or, if you must have absolutely 100% browser coverage including people who have not installed certain Windows updates under XP+IE, at minimal financial cost).
It's the doorlock equivalent of raising a stink that since you don't have a triple deadbolt, just don't lock the door at all.
No. Allowing the use of a self-signed certificate instead of the hassle of getting one with a verifiable trust chain is the door-lock equivalent of letting the person who installs your doors make a cheap simple easily picked lock look like a triple deadbolt lock, so the user thinks their stuff are protected by a triple deadbolt lock when it is actually protected by something much more flimsy.
If you want to use HTTPS, use it properly (which means having a certificate signed by a CA trusted by the users' browser) or your users will be warned that you are not using it properly. If you really must self-sign in a live environment for some reason, create your own CA key+cert and have your users install that as a trusted CA in their browsers (though this won't wash for a public site (good luck getting everyone to trust you to potentially sign certs for any name!) it is often done in corporate environments).
Is this ignoring their EULA which disclaims them from the very thing you are whining about?
Most clauses like that are not enforceable. There are some rights and expectations in consumer protection law that can not be waived in small print that way.
Of course this will vary from territory to territory so what is enforceable via EULA in yours may not be in mine, and you might have different statutory rights to start with. The overall legal status of click-wrap EULAs is a big fat grey area in most places too - in many cases they are not worth the paper they are not written on.
Before an exploit is demonstrated, a vulnerability is only theoretically exploitable.
That should be skewed by when the last unit was officially sold. Someone who bought the game 12 months ago has had considerably less time to use that part of it then someone who bought it on release day.
They have, by failure to act in setting up an alternative or allowing their users to do so without beaching the click-wrap license, deliberately made their product unfit for the purpose it was sold for.
While there should be some limits on the length of applicability of this, I don't see why they shouldn't be required to release the server code so their existing players can host it somewhere or perhaps offer a partial refund for those who are still actively playing the game.
Or they could simply be made to state, in readably sized text on the back cover of the game box and other promotional materials, that they guarantee the servers will run until a certain time (if things are taken down before then, users get a refund pro-rated from date of purchase, if they are taken down after then, then people were warned and can't complain). Then people can choose at the time of purchase whether they thing this is long enough to get their moneys worth out of the game. No need to legislate a time period: just make them promise something and hold them to what-ever the something is that they promise.
Most of the ones on the good side would be equally happy being paid to work for the other side.
Not exactly immoral, but more often than not amoral.
(which is generally their job: to ensure that things are legally correct by some technical definition of legal irrespective of wishy-washy complications like morality)
Anyone have a link to a simple test script that I could use to check the sites of our suppliers (and to verify our own server's configurations before)? None of the linked articles mention one that is readily available.
Hollywood loves your wife's tastes and is catering to them, not yours. Interesting bit on the BBC this weekend, in analysis - many films are being geared to be friendly to the Chinese audiences - Hollywood knows where the money is.
In some territories Pulp Fiction was re-edited so that all the segments followed in correct chronological order, as they didn't think the audience in those places would accept the events being told the way they were for the rest of us because their story telling traditions were far more fixed format-wise and the execs thought the disjoint style of the original edit would be too jarring for them to find interesting or enjoyable.
Not quite the same as tweaking the standard edit we all see to account for possible differences in how the average Chinese audience member takes in entertainment, but Hollywood has been tweaking films for foreign markets for many years where they think it might improve sales. This is separate from censorship, where the differing cuts are usually imposed by an official body in the given territory in order to fit to locally defined standards of what is acceptable: in this case the studios are self editing to try make more money.