Got certificate from startssl, but it's a pain. Couple of hours of totally pointless work.
I'm a StartSSL user and have a dozen or so certs from them. Creating a new account is the work of minutes, if that. Doing the domain verification process takes a few minutes at most. Getting the cert issued is a few minutes more. Starting from complete scratch to having a signed Class 1 cert is the work of maybe 15 minutes tops, even counting the time to generate a private key and CSR.
Using a utility like Cert Patrol on Firefox or Thunderbird is pretty trivial and will instantly alert you to something like that happening. It even provides varying degrees of warnings: if a server cert is nearing its expiration and changes to a different CA that's less suspicious than a cert firmly in the middle of its validity period changes CAs.
Changing between certain common CAs like Thawte, VeriSign, etc. is not uncommon (Facebook uses DigiCert and VeriSign-issued certs on different load balancers, which is annoying) but is frustrating as it results in a lot of warnings (which you can suppress to varying degrees). If CNNIC's CA showed up on something that I'm almost certain won't use it (Facebook, Gmail, my own server, etc.) then that's cause for alarm.
One can also remove the trust bits from the CNNIC (or any other CA) in their clients/browsers.
An easy solution to this is to use your ISPs outgoing mail server as a "smarthost".
Incoming mail comes directly to your server. Your mail client connects to your server to send outgoing mail and your server connects to your ISPs server to relay that outgoing mail.
It's just one extra hop (though it does put your outgoing mail at the mercy of your ISP, who can sometimes suck) but it solves a lot of the problems relating to running a mail server at home.
...which is still cheaper than many commercial certs.
The individual and organizational validation only charges a fee on the validation itself, not each certificate. If you only need one or two certs it may be worthwhile to go with someone like Comodo, RapidSSL, etc. that's inexpensive. If you need more than a few then the validation fee for StartSSL easily pays for itself.
Only if I didn't install the certificate separately on my device. But how do I use a CA signed certificate when my pop3-mail server has a dynamic IP? Get a certificate for a dyndns subdomain?
Sure. Or you could use your own domain (say example.com) and set a cname of "mail.example.com" to point at your_dyndns_name.dyndns.com. Get a free cert from StartSSL for "mail.example.com" and you're good to go.
Personally, I think the whole PKI thing is FUBAR, since only one super is allowed to vouch for a sub and you're effectively forced to trust someone else's CA collection (down to a certain vendor silently undoing your changes to the store on your operating system come every update check).
If you're referring to the Windows utility to update root certificates, that can be easily disabled.
To make digital trust workable I, end user, have to be able to choose whom to trust, a choice I currently do not have, in fact cannot have lest my intarwebz stop functioning!
Why not? It's quite possible to remove all root certificates from your system and only install those that you trust. If you're concerned about the trustworthiness of a root, you can install a certain server cert (though you may lose such benefits like OCSP or CRL checking, as those are signed by the roots).
Exactly. An open-access record of preprints is really handy as it allows one to really keep up with the state of research (as opposed to journals, which are often months behind where things are right now).
Take it with a grain of salt, of course, but it's useful in the same way that the Debian sid repository is useful.
Google offers a *great* service, for free (or now, for a very low price of $50/year if you're a small business).
That's $50/year per user. Still not a bad price (particularly if you're a small business).
However, when something goes *wrong* it can be very difficult to actually get Google to give you real honest-to-goodness end-user support.
That's wait the $50/year per user gets you, in addition to more storage. The now-deprecated free version of Google Apps doesn't have support. The paid version does. Evidently they don't suck when it comes to support and fixing stuff that's broken.
Mostly because I don't want to deal with the annoyances of running my own mail server and spam filters.
This. I can pay $10-$15/month for a decent VPS at a reputable host and run my own mail server, but the spam situation is intolerable. If the VPS goes down for whatever reason, I get no mail. Google has damn good spam filters and they handle all the issues related to disaster recovery, failover, etc.
$50/user/year is a bargain for businesses but it a bit steep for personal users. I've used their free service since shortly after it came out (what, in 2006 or something? I don't remember, it's been so long.) when one had to apply to the service and get approved. It's been fantastic. They really should continue to offer a free version for individuals, families, non-profits, and small organizations. At the very least, offer a discounted version.
Because the existing structure was intended to be only temporary and is not structurally sound. A collapse of the existing structure would release large amounts of radioactive dust and other crap into the atmosphere.
If stuff inside the existing structure starts to settle or move (for example, the Upper Biological Shield is held in place only by debris), dust can be released.
This new structure encloses the existing one in a way that (a) doesn't disturb the existing stuff and (b) is designed for long-term containment.
Natural fission reactors occur and can vent their byproducts to the atmosphere. Detection of fission products would not necessarily be a marker for life.
Indeed. I know a white South African who is now a US citizen. He annoys HR guys.
HR: "So, it says here you're African-American." Him: "Yup." HR: "...but you're white." Him: "You never asked my skin color. My parents are South African. I was born in South Africa. I grew up in South Africa. I spent much of my adult life in South Africa. I've since immigrated to the US and am a US citizen. How could I be anything other than African-American?" HR: "..."
"Completed" means doing all achievements, not "playing through the story". To me it seems quite natural that if it's the story that carries a game, people are not going to play through it multiple times to unlock every achievement.
Ah, you're right. I misunderstood the way things were categorized. Thanks for the correction.
I find it rather odd that certain story-based games (say, the Mass Effect series) have a modest rate of completion: according to that site, ME1 had 9.07% completion, ME2 12.00%, and ME3 5.33%. I understand the lack of completion of ME3, as there was a bit of controversy about the quality of the ending (or the lack thereof) so I could see people simply not bothering to finish, but it seems odd that the previous two games had such low completion rates -- they're pretty decent games so why not finish a game you've paid for? It seems my playing style differs from the average player.
I wonder how the statistics compare between PC and Xbox players. Now you've got me curious.
Sure, one could have different TLD variants (e.g. example.com/net/org/us/co.uk/etc.), but that isn't terribly useful in terms of continuing to offer service in the event of a TLD compromise: if the registry for your main domain gets borked some users may try a different TLD but most will simply give up -- how many people would try accessing Google under a different ccTLD? Same thing with email: if you have email at your domain and the TLD is hosed then emails can't automatically pick another TLD and try again -- if COM gets hacked, emails addressed to @gmail.com users aren't going to try @googlemail.com or other Google domains.
It's one thing to prepare for failures at one's own domain (for example, having a "network status" page at a different TLD using different DNS servers, having administrative mail accounts on a secondary domain/TLD, etc.) but a compromised TLD is a catastrophic failure and there's no sensible technical way for anyone "downstream" (that is, domain holders) to mitigate such an issue in a way that would be seamless and automatic to users.
I'd imagine the NIC could simply revert to a backup of their TLD zone and undo the changes -- the zone itself isn't infected and in need of purging, though the systems that can write to it may well be. I would hope that a NIC managing a national-level TLD has backups.
That said, how could any entity that relies on DNS have alternate plans to deal with this sort of thing? Its one thing to have off-site nameservers on a different network to provide some degree of fault tolerance for your own domain, but it's another thing if the TLD itself gets hosed and bad guys modify the zone to point at different nameservers. As far as I can tell there's no reasonable way for the holder of a domain name to prepare for the TLD getting compromised.
I hope this incident serves as a wakeup call for TLD owners everywhere so they can review their security policies.
I can get the security side of things, but how do you do that easily and with zero budget? What about a personal website? I can't afford an SSL certificate for that.
NameCheap. sells Comodo and GeoTrust domain-validated SSL certs for ~$8-$10/year. Thawte certs are $30. Those are well within an "essentially nil" budget range for even the smallest of businesses.
StartSSL.com has domain-validated certs for free. Additional validation and features (like wildcards) are available at nominal cost.
All of the above-mentioned certs are widely trusted by browsers, both on computers and mobile devices.
Certificate costs haven't been an issue for several years now. The days of needing to get VeriSign certs at outrageous prices are gone (though VeriSign still charges outrageous prices, naturally).
Is there any "SSL/HTTPS For Dummies With No Cash" manual somewhere, keeping in mind that most people with websites are code monkeys, not network administrators.
Enabling SSL/TLS for your web server usually requires the addition of a few lines in a configuration file that tell the server (a) to use SSL and (b) the location of the server's private key, public key, and any intermediate certificates from the certificate authority. The details vary based on your server software, but it's usually quite easy and instructions can be found on Google. The steps are basically: 1. Generate an RSA public key (usually 2048 bits, though 4096 is not uncommon. 1024 bits is deprecated.). 2. Create a certificate signing request (CSR) for your site using that private key. 3. Submit the CSR to the certificate authority for signing. 4. Complete whatever verification process the CA requires (for domain-validated certs this usually requires that you click a link sent to the email address listed in your domain's whois record, while high-validation-level certs may involve you sending the CA various documents). 5. One you are verified, the CA signs your CSR and sends you the signed certificate. In many cases they also direct you to download the required intermediate certificate that you'll also need. 6. You save the private key (readable to root only, of course), signed certificate, and the intermediate certificate to your server and configure your server software appropriately (usually only a few lines of configuration changes).
At present, most HTTPS sites should have their own unique IP address, which rules out most "personal" hosting. This is because Internet Explorer on Windows XP (still a substantial chunk of users) does not handle HTTPS-enabled virtualhosts. Pretty much any other browser on any other system does support it.
What's the difference between using this protocol and, uh, just disabling HTTP on your webserver? Or, from a user standpoint, just making sure you're using HTTPS via the URL?
Disabling HTTP can break things for users who manually enter URLs and forget the "https" or any number of other bad things. It's usually good form for a secure site to also run a plain-http server that redirects users to the secure site to avoid such confusion.
Only problem: ssl stripping. If a bad guy can intercept the connection between you and the secure site before the security has been negotiated then they can connect to the secure site in the normal way and present that page to you sans HTTPS and intercept anything you do there.
In short: browsers don't remember when a site "used to be secure but isn't today" and so don't present any warnings. This method tells the browser "For the next [time interval] you should only connect to me using a secure protocol. If not, the connection should fail." -- all that's required is that the user connect to the secure site at least once (e.g. from home or some other trusted network) to have the HSTS flag set for that site. If they try going to the coffee shop or some other place where there's a bad guy attempting ssl stripping then the connection will fail.
Indeed. The "heavy" part of SSL is doing the connection setup and exchange as it uses asymmetric algorithms like RSA or Diffie-Hellman for key exchange. The actual bulk encrypted transport is relatively lightweight. It never made much sense to me to spend the cycles to setup a secure connection, use it for protecting the login/password, and then dropping back to an insecure page when you could just keep the same connection secure for minimal additional resources.
More and more of people's lives take place on the internet.
Things that used to be ephemeral (telephone calls, letters, etc.) are becoming long-lived (emails, social networking posts, instant messages, etc.) and are useful investigative toosl.
Previously the police needed to get telephone records and then analyze the calling records to form connections. With social networks like Facebook, people do it for them.
Can the authorities abuse their position of power for various nefarious deeds? Absolutely. Are some of their requests legally or ethically dubious? No doubt. Nevertheless, there's plenty of legitimate reasons for governments to request user information and it should come as no surprise that the number of such requests is increasing.
That said, it's nice to see that major players like Google are quantifying the requests and the reasons behind them, as well as pushing back against such demands.
Indeed. PostFinance (a bank in Switzerland where I have an account as I'm a grad student there) has those exact same terminals. It's pretty slick.
Only disadvantage: they only allow one card to be linked to one's account for online access, even if it's a joint account. In my case, my wife has access to it because she does most of the financial stuff, but it's annoying. Naturally, we both have bank cards and can access the account via ATMs and the like, but only her card can be used for logging into the website.
Slashdot Mirror
I'll volunteer to receive those payments.
As for what to do with the money, how about a Scrooge McDuck-style vault?
Got certificate from startssl, but it's a pain. Couple of hours of totally pointless work.
I'm a StartSSL user and have a dozen or so certs from them. Creating a new account is the work of minutes, if that. Doing the domain verification process takes a few minutes at most. Getting the cert issued is a few minutes more. Starting from complete scratch to having a signed Class 1 cert is the work of maybe 15 minutes tops, even counting the time to generate a private key and CSR.
What did you do that took hours?
Using a utility like Cert Patrol on Firefox or Thunderbird is pretty trivial and will instantly alert you to something like that happening. It even provides varying degrees of warnings: if a server cert is nearing its expiration and changes to a different CA that's less suspicious than a cert firmly in the middle of its validity period changes CAs.
Changing between certain common CAs like Thawte, VeriSign, etc. is not uncommon (Facebook uses DigiCert and VeriSign-issued certs on different load balancers, which is annoying) but is frustrating as it results in a lot of warnings (which you can suppress to varying degrees). If CNNIC's CA showed up on something that I'm almost certain won't use it (Facebook, Gmail, my own server, etc.) then that's cause for alarm.
One can also remove the trust bits from the CNNIC (or any other CA) in their clients/browsers.
An easy solution to this is to use your ISPs outgoing mail server as a "smarthost".
Incoming mail comes directly to your server. Your mail client connects to your server to send outgoing mail and your server connects to your ISPs server to relay that outgoing mail.
It's just one extra hop (though it does put your outgoing mail at the mercy of your ISP, who can sometimes suck) but it solves a lot of the problems relating to running a mail server at home.
...which is still cheaper than many commercial certs.
The individual and organizational validation only charges a fee on the validation itself, not each certificate. If you only need one or two certs it may be worthwhile to go with someone like Comodo, RapidSSL, etc. that's inexpensive. If you need more than a few then the validation fee for StartSSL easily pays for itself.
Only if I didn't install the certificate separately on my device. But how do I use a CA signed certificate when my pop3-mail server has a dynamic IP? Get a certificate for a dyndns subdomain?
Sure. Or you could use your own domain (say example.com) and set a cname of "mail.example.com" to point at your_dyndns_name.dyndns.com. Get a free cert from StartSSL for "mail.example.com" and you're good to go.
sonic.net is pretty solid in that regard.
Disclaimer: family members are sonic customers but otherwise neither I nor anyone I know have any interest in the company.
Personally, I think the whole PKI thing is FUBAR, since only one super is allowed to vouch for a sub and you're effectively forced to trust someone else's CA collection (down to a certain vendor silently undoing your changes to the store on your operating system come every update check).
If you're referring to the Windows utility to update root certificates, that can be easily disabled.
To make digital trust workable I, end user, have to be able to choose whom to trust, a choice I currently do not have, in fact cannot have lest my intarwebz stop functioning!
Why not? It's quite possible to remove all root certificates from your system and only install those that you trust. If you're concerned about the trustworthiness of a root, you can install a certain server cert (though you may lose such benefits like OCSP or CRL checking, as those are signed by the roots).
Exactly. An open-access record of preprints is really handy as it allows one to really keep up with the state of research (as opposed to journals, which are often months behind where things are right now).
Take it with a grain of salt, of course, but it's useful in the same way that the Debian sid repository is useful.
Google offers a *great* service, for free (or now, for a very low price of $50/year if you're a small business).
That's $50/year per user. Still not a bad price (particularly if you're a small business).
However, when something goes *wrong* it can be very difficult to actually get Google to give you real honest-to-goodness end-user support.
That's wait the $50/year per user gets you, in addition to more storage. The now-deprecated free version of Google Apps doesn't have support. The paid version does. Evidently they don't suck when it comes to support and fixing stuff that's broken.
Mostly because I don't want to deal with the annoyances of running my own mail server and spam filters.
This. I can pay $10-$15/month for a decent VPS at a reputable host and run my own mail server, but the spam situation is intolerable. If the VPS goes down for whatever reason, I get no mail. Google has damn good spam filters and they handle all the issues related to disaster recovery, failover, etc.
$50/user/year is a bargain for businesses but it a bit steep for personal users. I've used their free service since shortly after it came out (what, in 2006 or something? I don't remember, it's been so long.) when one had to apply to the service and get approved. It's been fantastic. They really should continue to offer a free version for individuals, families, non-profits, and small organizations. At the very least, offer a discounted version.
Because the existing structure was intended to be only temporary and is not structurally sound. A collapse of the existing structure would release large amounts of radioactive dust and other crap into the atmosphere.
If stuff inside the existing structure starts to settle or move (for example, the Upper Biological Shield is held in place only by debris), dust can be released.
This new structure encloses the existing one in a way that (a) doesn't disturb the existing stuff and (b) is designed for long-term containment.
Natural fission reactors occur and can vent their byproducts to the atmosphere. Detection of fission products would not necessarily be a marker for life.
Indeed. I know a white South African who is now a US citizen. He annoys HR guys.
HR: "So, it says here you're African-American."
Him: "Yup."
HR: "...but you're white."
Him: "You never asked my skin color. My parents are South African. I was born in South Africa. I grew up in South Africa. I spent much of my adult life in South Africa. I've since immigrated to the US and am a US citizen. How could I be anything other than African-American?"
HR: "..."
"Completed" means doing all achievements, not "playing through the story". To me it seems quite natural that if it's the story that carries a game, people are not going to play through it multiple times to unlock every achievement.
Ah, you're right. I misunderstood the way things were categorized. Thanks for the correction.
That's a remarkably interesting site. Thanks.
I find it rather odd that certain story-based games (say, the Mass Effect series) have a modest rate of completion: according to that site, ME1 had 9.07% completion, ME2 12.00%, and ME3 5.33%. I understand the lack of completion of ME3, as there was a bit of controversy about the quality of the ending (or the lack thereof) so I could see people simply not bothering to finish, but it seems odd that the previous two games had such low completion rates -- they're pretty decent games so why not finish a game you've paid for? It seems my playing style differs from the average player.
I wonder how the statistics compare between PC and Xbox players. Now you've got me curious.
Sure, one could have different TLD variants (e.g. example.com/net/org/us/co.uk/etc.), but that isn't terribly useful in terms of continuing to offer service in the event of a TLD compromise: if the registry for your main domain gets borked some users may try a different TLD but most will simply give up -- how many people would try accessing Google under a different ccTLD? Same thing with email: if you have email at your domain and the TLD is hosed then emails can't automatically pick another TLD and try again -- if COM gets hacked, emails addressed to @gmail.com users aren't going to try @googlemail.com or other Google domains.
It's one thing to prepare for failures at one's own domain (for example, having a "network status" page at a different TLD using different DNS servers, having administrative mail accounts on a secondary domain/TLD, etc.) but a compromised TLD is a catastrophic failure and there's no sensible technical way for anyone "downstream" (that is, domain holders) to mitigate such an issue in a way that would be seamless and automatic to users.
I'd imagine the NIC could simply revert to a backup of their TLD zone and undo the changes -- the zone itself isn't infected and in need of purging, though the systems that can write to it may well be. I would hope that a NIC managing a national-level TLD has backups.
That said, how could any entity that relies on DNS have alternate plans to deal with this sort of thing? Its one thing to have off-site nameservers on a different network to provide some degree of fault tolerance for your own domain, but it's another thing if the TLD itself gets hosed and bad guys modify the zone to point at different nameservers. As far as I can tell there's no reasonable way for the holder of a domain name to prepare for the TLD getting compromised.
I hope this incident serves as a wakeup call for TLD owners everywhere so they can review their security policies.
FYI: the https://cert.startcom.org/ site is, as far as I know, somewhat deprecated. The more up-to-date URL is https://www.startssl.com/
I can get the security side of things, but how do you do that easily and with zero budget? What about a personal website? I can't afford an SSL certificate for that.
NameCheap. sells Comodo and GeoTrust domain-validated SSL certs for ~$8-$10/year. Thawte certs are $30. Those are well within an "essentially nil" budget range for even the smallest of businesses.
StartSSL.com has domain-validated certs for free. Additional validation and features (like wildcards) are available at nominal cost.
All of the above-mentioned certs are widely trusted by browsers, both on computers and mobile devices.
Certificate costs haven't been an issue for several years now. The days of needing to get VeriSign certs at outrageous prices are gone (though VeriSign still charges outrageous prices, naturally).
Is there any "SSL/HTTPS For Dummies With No Cash" manual somewhere, keeping in mind that most people with websites are code monkeys, not network administrators.
Enabling SSL/TLS for your web server usually requires the addition of a few lines in a configuration file that tell the server (a) to use SSL and (b) the location of the server's private key, public key, and any intermediate certificates from the certificate authority. The details vary based on your server software, but it's usually quite easy and instructions can be found on Google. The steps are basically:
1. Generate an RSA public key (usually 2048 bits, though 4096 is not uncommon. 1024 bits is deprecated.).
2. Create a certificate signing request (CSR) for your site using that private key.
3. Submit the CSR to the certificate authority for signing.
4. Complete whatever verification process the CA requires (for domain-validated certs this usually requires that you click a link sent to the email address listed in your domain's whois record, while high-validation-level certs may involve you sending the CA various documents).
5. One you are verified, the CA signs your CSR and sends you the signed certificate. In many cases they also direct you to download the required intermediate certificate that you'll also need.
6. You save the private key (readable to root only, of course), signed certificate, and the intermediate certificate to your server and configure your server software appropriately (usually only a few lines of configuration changes).
At present, most HTTPS sites should have their own unique IP address, which rules out most "personal" hosting. This is because Internet Explorer on Windows XP (still a substantial chunk of users) does not handle HTTPS-enabled virtualhosts. Pretty much any other browser on any other system does support it.
What's the difference between using this protocol and, uh, just disabling HTTP on your webserver? Or, from a user standpoint, just making sure you're using HTTPS via the URL?
Disabling HTTP can break things for users who manually enter URLs and forget the "https" or any number of other bad things. It's usually good form for a secure site to also run a plain-http server that redirects users to the secure site to avoid such confusion.
Only problem: ssl stripping. If a bad guy can intercept the connection between you and the secure site before the security has been negotiated then they can connect to the secure site in the normal way and present that page to you sans HTTPS and intercept anything you do there.
In short: browsers don't remember when a site "used to be secure but isn't today" and so don't present any warnings. This method tells the browser "For the next [time interval] you should only connect to me using a secure protocol. If not, the connection should fail." -- all that's required is that the user connect to the secure site at least once (e.g. from home or some other trusted network) to have the HSTS flag set for that site. If they try going to the coffee shop or some other place where there's a bad guy attempting ssl stripping then the connection will fail.
I've opted to use https only on Facebook for a year or so and haven't noticed any discernible difference.
Indeed. The "heavy" part of SSL is doing the connection setup and exchange as it uses asymmetric algorithms like RSA or Diffie-Hellman for key exchange. The actual bulk encrypted transport is relatively lightweight. It never made much sense to me to spend the cycles to setup a secure connection, use it for protecting the login/password, and then dropping back to an insecure page when you could just keep the same connection secure for minimal additional resources.
More and more of people's lives take place on the internet.
Things that used to be ephemeral (telephone calls, letters, etc.) are becoming long-lived (emails, social networking posts, instant messages, etc.) and are useful investigative toosl.
Previously the police needed to get telephone records and then analyze the calling records to form connections. With social networks like Facebook, people do it for them.
Can the authorities abuse their position of power for various nefarious deeds? Absolutely. Are some of their requests legally or ethically dubious? No doubt. Nevertheless, there's plenty of legitimate reasons for governments to request user information and it should come as no surprise that the number of such requests is increasing.
That said, it's nice to see that major players like Google are quantifying the requests and the reasons behind them, as well as pushing back against such demands.
Indeed. PostFinance (a bank in Switzerland where I have an account as I'm a grad student there) has those exact same terminals. It's pretty slick.
Only disadvantage: they only allow one card to be linked to one's account for online access, even if it's a joint account. In my case, my wife has access to it because she does most of the financial stuff, but it's annoying. Naturally, we both have bank cards and can access the account via ATMs and the like, but only her card can be used for logging into the website.