I seem to recall that Splinter Cell: Chaos Theory went for some time (about a year or so) prior to being cracked. It's not exactly obscure.
It was really annoying, as I ended up purchasing it legitimately but ran into trouble playing it on a Windows Vista system (later, once it was cracked, I got the no-cd crack and it worked just fine).
FYI: Fallout 3 is available on Steam now. I got the Game of the Year Edition (all the DLC included), as well as Fallout and Fallout 2 in some discounted bundle a month or two ago.
Now, for Fallout: New Vegas to go "Game of the Year" and be available for discount on Steam...
Steam requires that you be online once to validate the license. After that, you can go into "offline mode" for as much as you please. It's pretty transparent, and hasn't been a problem for me.
Personally, I prefer buying games on Steam: automatic patches, frequent discounts for various games on Steam, in-game voice/text chat, Valve Anti-Cheat on many multiplayer games (while not perfect, it's better than nothing), and not having to deal with license keys and physical media are major perks for me.
Is there DRM? Sure. Is it far less obnoxious than the stuff on other games (I'm looking at you, Splinter Cell: Chaos Theory)? Definitely.
"Huge amounts"? GoDaddy offers widely-trusted certs (their roots are in all major browsers, and also chain back to the old ValiCert root so it works with ancient browsers) for about $13/year. Hardly "huge amounts".
StartSSL has their root in all major browsers, and they issue certs for free. (Naturally, they also offer Class 2 and EV certs for money, but their basic domain-validated certs are free.) While the PKI model has its flaws, StartSSL seems to be doing The Right Thing within the confines of the model (4096-bit roots, 2048-bit minimum key length, checks for weak keys, no internal/unqualified names, etc.).
In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?
Actually, you need only show your identity documents to someone in their web of trust once. The identity validation is good "for life", and is associated with your cacert account. The certificates issued by cacert are valid for a maximum of two years, after which time one can get fresh certs (indeed, one can get certs revoked and new ones issued at any time).
Fark user FloydA: I think if boys play this game, they will grow up to abuse women, in exactly the same way that I played Asteroids when I was young, and I grew up to be a triangle.
(said in regards to the "Capture the Babe" multiplayer level category in Duke Nukem Forever)
Isn't this exactly what Extended Validation Certificates are supposed to resolve? Only certain validated certificate authorities are allowed to issue them.
The problem is that any of the CAs that can issue EV certs can issue EV certs to any entity, and they will all be "trusted" by browsers.
Yes, they're supposed to only issue to entities that they've validated, but that doesn't help if one gets compromised and starts issuing technically-valid EV certs to unauthorized parties.
I've been using their "residential" software/service for several months now on 11 computers in my family (the family plan is a good deal). When my laptop got stolen (it used full-disk encryption, so I'm not worried about the thieves getting to the data), I was able to restore the data from CrashPlan in a few hours without a problem. It saved my bacon.
I have the software installed on Windows, Linux (Ubuntu and Red Hat), and Mac systems and it works quite well.
We've been trialling their commercial software at my work for a bit, and it looks extremely promising. I only ran into a hiccup when we had the it was scanning enormous datasets (multi-terabytes, several million files) on a Red Hat server. However, for more "ordinary" desktop systems, it works great. Now, we just need the budget to buy it (it's not unaffordable, but I work at a university and money is very tight).
Disclaimer: I am a paying customer of CrashPlan, but otherwise have no affiliation with them.
Personally i think organisations like banks should issue their own certificates, that way you are not trusting any third party. For other sites, who knows...
That raises the question of authentication (much like for self-signed certs): how do you know the bank's certificate is actually legitimate? Yes, you could contact the bank and ask for their key fingerprints, or be issued the key information when one opens an account and validate it when one gets home (much like SSH)...but I suspect that >99% of people would not know how to do this properly. This is a Bad Thing.
Can you cite any EV-issuing CA that does not do a "more thorough background check" of an applicant? If so, I'm sure the auditors and browser vendors would be interested to know.
Others have suggested some sort of cross-signatures for high-value sites, such banks. By having a certificate signed by both a commercial vendor (VeriSign and the like) and from a regulatory body (e.g. the banking regulators for that particular country), that would offer higher levels of validation.
Of course, users will continue to get phished by look-alike sites (who display little padlock icons in the site content just like the sites they're spoofing, not to mention sites where the login page is insecure [offering no authentication of the remote site prior to submitting credentials] even though the login information is submitted to an SSL-secured page)
As I've mentioned previously, the current PKI implementation is not perfect. It has its flaws, and can certainly be improved. Even with all of its flaws, it's had remarkably few problems over the years. Adding features in browsers like showing additional "trust flags" for cross-signed certs would be a nice start.
Microsoft released an advisory about this subject, which also included an update to blacklist those Comodo certs (the blacklisted code-signing certs from Microsoft are from a separate incident from 2001). It rolled out over Windows Update as a critical update several days ago.
This shouldn't really be necessary, as the certs were also revoked by Comodo, and are available through their CRLs (which aren't queried by default) or by OCSP (which is). Nevertheless, the browser vendors (Microsoft in this case) are being a bit more thorough.
However, people are now discussing removing the Comodo root certificates, as they feel that Comodo has been too irresponsible in their issuing policies (or in their RA security policies) to warrant any trust at all.
That's why it's a good idea to have an offline root certificate that is only used for signing one or more intermediate issuing certificates. These intermediates then sign certs issued to the public.
If the intermediates get compromised, the root is brought out of storage, issues a revocation for the intermediates (which also revokes any keys issued by the now-compromised intermediate), signs a new intermediate, and is put back into storage. This greatly reduces the risk of the root being compromised. Since roots can't really be revoked (short of having the browsers remove them), keeping the roots offline and using intermediates results in a less-catastrophic failure mode.
You can also not bother using CRLs, and just use OCSP, which is turned on by default (EV certificates require it or else the browser won't display the "green bar").
As it does live checks on only the certificates presented right then, rather than downloading the whole CRL at intervals, OCSP uses less network resources for both you and the CA, updates faster (CRLs update every few days), and is generally superior in all ways. Like CRLs, OCSP responses are signed by the CA that issued them, and so cannot be tampered with.
You can even have your browser set to not trust the certificate presented if the OCSP query fails, which is a good fail-safe. I wish there was a "warn if OCSP check fails" option, rather than "fail silently and allow connection to proceed if OCSP fails" and "fail noisily and not work if OCSP fails". The former leaves people vulnerable, while the latter presents DoS attack targets.
Pushing out OS and browser updates to manually revoke those certificates is not a bad idea, particularly for those who have OCSP disabled for whatever reason, but there's not really any reason to manually install CRLs when OCSP exists.
That's exactly what SSL is for. What you're thinking of is the key distribution. If you don't know who's signing the keys, then SSL cannot help you.
Fair enough.
My point was that CAs rarely mistakenly sign keys for fraudulent entities. Has it happened? Absolutely. Is it common? No. With EV certs becoming more popular for big-name sites (e.g. banks and the like), users can have a reasonable confidence in that the site they're visiting is legitimate. Non-EV certs provide a more modest assurance. Non-SSL sites offer essentially no assurance, which is the current situation for most sites.
In short, using even an occasionally-flawed system like the current SSL infrastructure is far better than not using anything at all, which is what's currently going on.
(Ever looked at how many "trusted" CA's your browser includes by default? Are you familiar enough with even 10% of them to trust them for this role?)
Yes, I've looked at the list. Rather than prune it of CAs that I may consider to be bad (they do, after all, have to undergo audits and the like to be added to the major browser lists), I make it a habit to always hover over the Firefox SSL indicator (which then displays the name of the CA) when I visit an SSL-secured site, and make sure it's a reasonable CA (e.g. one in North America or Western Europe for essentially all the sites I visit) for the site. I also have the Certificate Patrol plugin to detect spoofing.
Of course, the average user doesn't do anywhere near this much checking (which admittedly isn't much). However, I stand by my above point that even with its flaws, using SSL on everything (or at least more things) is far better than keeping things they way they are now.
I ask myself what would happen if the websites were small ones, do the issuer move that fast and browsers fix that fast too?
I am not that sure. It is time that all CA must provide Certificate Revocation List and not be optional. Anye advantage of using a CA that provide it is nullified by the existence of CAs without CRL?
All CAs do provide CRLs, but it's enormously inefficient to provide the files to brazillions of end-users, as they need to download the entire files at regular intervals and likely don't visit more than a handful of sites that may be listed in the CRL. There's also a window in between when CRLs are published and when the user actually downloads the list, usually on the order of a week or so.
Instead, most CAs and essentially all browsers support OCSP, which allows for live revocation checking. This has been the case for some time, as there's essentially no window where revoked certificates would be considered valid and it dramatically reduces the amount of network resources needed as the CAs need only provide replies to individual, on-demand queries rather than distributing much larger CRLs to everyone, whether they need it or not.
It's not needed, so long as the "Use the Online Certificate Status Protocol..." box is ticked, and the "Validate a certificate if it specifies an OCSP server" box is selected in the "Validation" section under the "Encryption" tab in Firefox preferences.
You sure? OCSP validation is a requirement for Extended Validation certificates. If OCSP is not enabled, the certs will still work, but they'll show up as ordinary SSL certs rather than the "green bar" EV certs.
Because an uncommon, widely-publicized, already-fixed incident that affects a very small number of sites is somehow worse than the status quo, where there's no validation of sites, no assurance of a lack of tampering of data in transit, or of illicit interception of data, right?
Hurricane Electric ran their Fremont datacenter on generator power for about one week during power equipment maintenance by the local electric company (evidently power was going to be unreliable for that week, so they opted to run full-time on the generator rather than switch on and off frequently), according to a rep I met with several years ago. He claims they burned through about 5,000 gallons of diesel during that time.
Really? Doesn't seem that hard; I access my work/university mail (I work at a university) with Thunderbird, and use the web-based interface for my personal account open in a browser. Not impractical at all.
If I were inclined, I could access everything in Thunderbird, but I like keeping things separate and not storing personal mail on a work computer.
It's not really abusing DNS, but it seems really foolish to found a business that relies upon a (at the time) potentially unstable (and now definitely unstable) foreign country's ccTLD.
Google's shortener, goo.gl, uses Greenland's ccTLD, which is quite stable. Austria (.at), Iceland (.is), and other clever-sounding ccTLDs are in stable countries with good infrastructure. Libya...not so much.
*shrugs* My cheap $360 Asus Eee PC 1015PEM netbook seems to have better build quality than that. No stripped screws or unlocked ZIF connectors from the factory. (Naturally, I partially stripped a screw opening it up to upgrade the hard disk.)
That said, the MacBook beats the everliving hell out of the Eee PC in terms of performance. Still, $1,800 for a laptop is entirely too much in my view -- I have my netbook for portability and my desktop at home for high-performance stuff.
Are you sure they don't block outbound port 25? Searching for "comcast port 25 blocking" seems to suggest that they are, in fact doing so, and have been since 2004.
Cox, one of Comcast's major competitors, also blocks port 25 on residential lines. Naturally, connections to port 587 go through without any problems. They also block inbound port 25 and port 80, which prevent people from running a home mail or web server, even if they use Cox's "smarthost" outbound mail server.
I would also like an "opt-in" option for outbound (and inbound!) port 25. Home servers are quite useful, and one would presume that someone asking for a port being opened would be Somewhat Clueful.
Slashdot Mirror
I seem to recall that Splinter Cell: Chaos Theory went for some time (about a year or so) prior to being cracked. It's not exactly obscure.
It was really annoying, as I ended up purchasing it legitimately but ran into trouble playing it on a Windows Vista system (later, once it was cracked, I got the no-cd crack and it worked just fine).
FYI: Fallout 3 is available on Steam now. I got the Game of the Year Edition (all the DLC included), as well as Fallout and Fallout 2 in some discounted bundle a month or two ago.
Now, for Fallout: New Vegas to go "Game of the Year" and be available for discount on Steam...
Steam requires that you be online once to validate the license. After that, you can go into "offline mode" for as much as you please. It's pretty transparent, and hasn't been a problem for me.
Personally, I prefer buying games on Steam: automatic patches, frequent discounts for various games on Steam, in-game voice/text chat, Valve Anti-Cheat on many multiplayer games (while not perfect, it's better than nothing), and not having to deal with license keys and physical media are major perks for me.
Is there DRM? Sure. Is it far less obnoxious than the stuff on other games (I'm looking at you, Splinter Cell: Chaos Theory)? Definitely.
"Huge amounts"? GoDaddy offers widely-trusted certs (their roots are in all major browsers, and also chain back to the old ValiCert root so it works with ancient browsers) for about $13/year. Hardly "huge amounts".
StartSSL has their root in all major browsers, and they issue certs for free. (Naturally, they also offer Class 2 and EV certs for money, but their basic domain-validated certs are free.) While the PKI model has its flaws, StartSSL seems to be doing The Right Thing within the confines of the model (4096-bit roots, 2048-bit minimum key length, checks for weak keys, no internal/unqualified names, etc.).
In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?
Actually, you need only show your identity documents to someone in their web of trust once. The identity validation is good "for life", and is associated with your cacert account. The certificates issued by cacert are valid for a maximum of two years, after which time one can get fresh certs (indeed, one can get certs revoked and new ones issued at any time).
Fark user FloydA: I think if boys play this game, they will grow up to abuse women, in exactly the same way that I played Asteroids when I was young, and I grew up to be a triangle.
(said in regards to the "Capture the Babe" multiplayer level category in Duke Nukem Forever)
Isn't this exactly what Extended Validation Certificates are supposed to resolve? Only certain validated certificate authorities are allowed to issue them.
The problem is that any of the CAs that can issue EV certs can issue EV certs to any entity, and they will all be "trusted" by browsers.
Yes, they're supposed to only issue to entities that they've validated, but that doesn't help if one gets compromised and starts issuing technically-valid EV certs to unauthorized parties.
I've been using their "residential" software/service for several months now on 11 computers in my family (the family plan is a good deal). When my laptop got stolen (it used full-disk encryption, so I'm not worried about the thieves getting to the data), I was able to restore the data from CrashPlan in a few hours without a problem. It saved my bacon.
I have the software installed on Windows, Linux (Ubuntu and Red Hat), and Mac systems and it works quite well.
We've been trialling their commercial software at my work for a bit, and it looks extremely promising. I only ran into a hiccup when we had the it was scanning enormous datasets (multi-terabytes, several million files) on a Red Hat server. However, for more "ordinary" desktop systems, it works great. Now, we just need the budget to buy it (it's not unaffordable, but I work at a university and money is very tight).
Disclaimer: I am a paying customer of CrashPlan, but otherwise have no affiliation with them.
Personally i think organisations like banks should issue their own certificates, that way you are not trusting any third party. For other sites, who knows...
That raises the question of authentication (much like for self-signed certs): how do you know the bank's certificate is actually legitimate? Yes, you could contact the bank and ask for their key fingerprints, or be issued the key information when one opens an account and validate it when one gets home (much like SSH)...but I suspect that >99% of people would not know how to do this properly. This is a Bad Thing.
Can you cite any EV-issuing CA that does not do a "more thorough background check" of an applicant? If so, I'm sure the auditors and browser vendors would be interested to know.
Others have suggested some sort of cross-signatures for high-value sites, such banks. By having a certificate signed by both a commercial vendor (VeriSign and the like) and from a regulatory body (e.g. the banking regulators for that particular country), that would offer higher levels of validation.
Of course, users will continue to get phished by look-alike sites (who display little padlock icons in the site content just like the sites they're spoofing, not to mention sites where the login page is insecure [offering no authentication of the remote site prior to submitting credentials] even though the login information is submitted to an SSL-secured page)
As I've mentioned previously, the current PKI implementation is not perfect. It has its flaws, and can certainly be improved. Even with all of its flaws, it's had remarkably few problems over the years. Adding features in browsers like showing additional "trust flags" for cross-signed certs would be a nice start.
Microsoft released an advisory about this subject, which also included an update to blacklist those Comodo certs (the blacklisted code-signing certs from Microsoft are from a separate incident from 2001). It rolled out over Windows Update as a critical update several days ago.
This shouldn't really be necessary, as the certs were also revoked by Comodo, and are available through their CRLs (which aren't queried by default) or by OCSP (which is). Nevertheless, the browser vendors (Microsoft in this case) are being a bit more thorough.
However, people are now discussing removing the Comodo root certificates, as they feel that Comodo has been too irresponsible in their issuing policies (or in their RA security policies) to warrant any trust at all.
That's why it's a good idea to have an offline root certificate that is only used for signing one or more intermediate issuing certificates. These intermediates then sign certs issued to the public.
If the intermediates get compromised, the root is brought out of storage, issues a revocation for the intermediates (which also revokes any keys issued by the now-compromised intermediate), signs a new intermediate, and is put back into storage. This greatly reduces the risk of the root being compromised. Since roots can't really be revoked (short of having the browsers remove them), keeping the roots offline and using intermediates results in a less-catastrophic failure mode.
You can also not bother using CRLs, and just use OCSP, which is turned on by default (EV certificates require it or else the browser won't display the "green bar").
As it does live checks on only the certificates presented right then, rather than downloading the whole CRL at intervals, OCSP uses less network resources for both you and the CA, updates faster (CRLs update every few days), and is generally superior in all ways. Like CRLs, OCSP responses are signed by the CA that issued them, and so cannot be tampered with.
You can even have your browser set to not trust the certificate presented if the OCSP query fails, which is a good fail-safe. I wish there was a "warn if OCSP check fails" option, rather than "fail silently and allow connection to proceed if OCSP fails" and "fail noisily and not work if OCSP fails". The former leaves people vulnerable, while the latter presents DoS attack targets.
Pushing out OS and browser updates to manually revoke those certificates is not a bad idea, particularly for those who have OCSP disabled for whatever reason, but there's not really any reason to manually install CRLs when OCSP exists.
That's exactly what SSL is for. What you're thinking of is the key distribution. If you don't know who's signing the keys, then SSL cannot help you.
Fair enough.
My point was that CAs rarely mistakenly sign keys for fraudulent entities. Has it happened? Absolutely. Is it common? No. With EV certs becoming more popular for big-name sites (e.g. banks and the like), users can have a reasonable confidence in that the site they're visiting is legitimate. Non-EV certs provide a more modest assurance. Non-SSL sites offer essentially no assurance, which is the current situation for most sites.
In short, using even an occasionally-flawed system like the current SSL infrastructure is far better than not using anything at all, which is what's currently going on.
(Ever looked at how many "trusted" CA's your browser includes by default? Are you familiar enough with even 10% of them to trust them for this role?)
Yes, I've looked at the list. Rather than prune it of CAs that I may consider to be bad (they do, after all, have to undergo audits and the like to be added to the major browser lists), I make it a habit to always hover over the Firefox SSL indicator (which then displays the name of the CA) when I visit an SSL-secured site, and make sure it's a reasonable CA (e.g. one in North America or Western Europe for essentially all the sites I visit) for the site. I also have the Certificate Patrol plugin to detect spoofing.
Of course, the average user doesn't do anywhere near this much checking (which admittedly isn't much). However, I stand by my above point that even with its flaws, using SSL on everything (or at least more things) is far better than keeping things they way they are now.
I ask myself what would happen if the websites were small ones, do the issuer move that fast and browsers fix that fast too?
I am not that sure. It is time that all CA must provide Certificate Revocation List and not be optional. Anye advantage of using a CA that provide it is nullified by the existence of CAs without CRL?
All CAs do provide CRLs, but it's enormously inefficient to provide the files to brazillions of end-users, as they need to download the entire files at regular intervals and likely don't visit more than a handful of sites that may be listed in the CRL. There's also a window in between when CRLs are published and when the user actually downloads the list, usually on the order of a week or so.
Instead, most CAs and essentially all browsers support OCSP, which allows for live revocation checking. This has been the case for some time, as there's essentially no window where revoked certificates would be considered valid and it dramatically reduces the amount of network resources needed as the CAs need only provide replies to individual, on-demand queries rather than distributing much larger CRLs to everyone, whether they need it or not.
In short: don't worry.
It's not needed, so long as the "Use the Online Certificate Status Protocol..." box is ticked, and the "Validate a certificate if it specifies an OCSP server" box is selected in the "Validation" section under the "Encryption" tab in Firefox preferences.
OCSP > CRL
You sure? OCSP validation is a requirement for Extended Validation certificates. If OCSP is not enabled, the certs will still work, but they'll show up as ordinary SSL certs rather than the "green bar" EV certs.
All major browsers have OCSP enabled by default.
Because an uncommon, widely-publicized, already-fixed incident that affects a very small number of sites is somehow worse than the status quo, where there's no validation of sites, no assurance of a lack of tampering of data in transit, or of illicit interception of data, right?
Hurricane Electric ran their Fremont datacenter on generator power for about one week during power equipment maintenance by the local electric company (evidently power was going to be unreliable for that week, so they opted to run full-time on the generator rather than switch on and off frequently), according to a rep I met with several years ago. He claims they burned through about 5,000 gallons of diesel during that time.
Their generator is big.
Really? Doesn't seem that hard; I access my work/university mail (I work at a university) with Thunderbird, and use the web-based interface for my personal account open in a browser. Not impractical at all.
If I were inclined, I could access everything in Thunderbird, but I like keeping things separate and not storing personal mail on a work computer.
How much gunpowder could you buy for $30 (or just raw ingredients for bombs)?
About a pound and a half.
It's not really abusing DNS, but it seems really foolish to found a business that relies upon a (at the time) potentially unstable (and now definitely unstable) foreign country's ccTLD.
Google's shortener, goo.gl, uses Greenland's ccTLD, which is quite stable. Austria (.at), Iceland (.is), and other clever-sounding ccTLDs are in stable countries with good infrastructure. Libya...not so much.
Time flies: 2TB disks are only about $80 now. Things keep getting cheaper...
*shrugs* My cheap $360 Asus Eee PC 1015PEM netbook seems to have better build quality than that. No stripped screws or unlocked ZIF connectors from the factory. (Naturally, I partially stripped a screw opening it up to upgrade the hard disk.)
That said, the MacBook beats the everliving hell out of the Eee PC in terms of performance. Still, $1,800 for a laptop is entirely too much in my view -- I have my netbook for portability and my desktop at home for high-performance stuff.
China isn't even on the list for the last 30 days:
#1 India (18.3%)
#2 Brazil (9.5%)
#3 Russia (7.0%)
#4 Ukraine (5.1%)
#5 Vietnam (3.9%)
#6 Italy (3.3%)
#7 Germany (3.1%)
#8 Thailand (2.8%)
#9 Kazakhstan (2.5%)
#10 Romania (2.5%)
#11 Colombia (2.5%)
#12 Argentina (2.3%)
#13 Indonesia (2.3%)
#14 South Korea (2.2%)
#15 Taiwan (2.0%)
#16 United States (1.9%)
#17 Great Britain (1.9%)
#18 Poland (1.8%)
#19 Morocco (1.7%)
#20 Pakistan (1.6%)
#21 Peru (1.5%)
#22 Spain (1.4%)
#23 Israel (1.4%)
#24 Saudi Arabia (1.4%)
#25 Chile (1.3%)
Source. (Click "top 25", then select "last 30 days".)
For all time, the top 5 are:
#1 China (10.1%)
#2 Brazil (8.9%)
#3 United States (7.4%)
#4 Germany (6.5%)
#5 Russia (6.0%)
Are you sure they don't block outbound port 25? Searching for "comcast port 25 blocking" seems to suggest that they are, in fact doing so, and have been since 2004.
Cox, one of Comcast's major competitors, also blocks port 25 on residential lines. Naturally, connections to port 587 go through without any problems. They also block inbound port 25 and port 80, which prevent people from running a home mail or web server, even if they use Cox's "smarthost" outbound mail server.
I would also like an "opt-in" option for outbound (and inbound!) port 25. Home servers are quite useful, and one would presume that someone asking for a port being opened would be Somewhat Clueful.