First of all, I had to get a dedicated server, because a bunch of other sites were running on the same server, and the hosting company doesn't offer additional IP addresses.
Then I wanted to get an SSL certificate. I picked Comodo, because they seemed to offer the cheapest full business validation certificate, but then accidentally bought a domain only certificate because their marketing was so confusing. Their friendly customer service walked me through a complicated process for changing my order.
To get the certificate issued, it took me a week to collect the documents they requested. I had to make sure my business was listed in the yellow pages, so they could send me an automatic phone call for verifying my number.
After every step in the process, they told me to log into their online management area, which was offline from time to time.
I had to confirm my email address by clicking a link about a dozen times. Half of the emails were missing the confirmation link.
Twice I got an email telling me my order will soon be processed, and nothing happened for two days. I had to open tickets in some online support area or send them emails to get them to continue processing.
All in all it took me a month to get SSL working. Now I understand why so many sites do not use HTTPS.
I went through the dance with Startcom and agree with the article that the web interface has horrible workflow. However they were clearly doing their best to verify that it actually was a business they were creating an account for. For example, they ignored the phone number I gave them, and instead called on the publicly-listed phone number they found on the internet.
It really does not add anything to the equation. Just extra costs and work for you.
It's been studied and pointed out that a green-bar does nothing to conversions and sales.
I suggest skipping it always, but often times a higher business type will override the suggestion of whomever has to implement it and maintain it - simply because they really don't get it or don't care about the cost (which isn't really that much, but still, you have to jump through hoops getting the docs in order).
I'm not debating this point, but if you have some citations for this assertion, I'd love to read them. I've always heard and read otherwise.
I just completed a multiple-month-long process of converting a dynamic-domain application to support SSL-friendly URIs and implementing SSL on it's web servers based entirely on the concept of adding a green bar for boosting conversions (data isn't quite in yet to verify we did anything). I would really hope that I didn't waste multiple iterations on a pipe dream.
Those "Get better conversion rates with EV Certs" internal studies are pure marketing B.S. by the SSL vendors. Do not trust what they say.
Every single person that has tested this on his site has come to the same exact conclusion - the green-bar has no meaning to the consumer, nor do they even notice it.
The EV certs contain extra information so are likely to be a little larger, but we are talking at most a couple of hundred bytes here so the extra download time getting the cert and CPU time verifying things are not going to be significant.
People do tend to have larger key sizes on EV certs (2048 or 4096 bit rather than 1024 or 2048 (though 1024 bit keys are increasingly rare even for "standard" certificates)) which might impose a measurable latency difference on a mobile (or other low-power) device due to the math involved in verifying the site against the certificate, but nothing like the order of magnitude that link mentions.
Of course it adds something: It makes it more difficult for someone else to go buy a SSL certificate in your name. Security isn't just about driving sales, it's also about protecting yourself and your customers.
No it doesn't. Just because you wasted money on a joke process, doesn't mean "evil attacker X" has to do it too. They can just go ahead and buy a regular cert for your domain still.
I guess I was more trying to convey that it's reassuring to know that Startcom (at least) go to some effort to investigate their verification, and it's not just a bits-in-bits-out process.
This being said, I'm in a business and if I leave and another ops person comes along, the semantics of 'business' versus 'personal' account makes their job a little easier. I'm certainly not an expert in the area of SSL, but from long experience in other fields, it's a pain in the arse managing 'business accounts' that are really repurposed individual/private accounts.
Got any source? Would really like to show that to some folks here ...
Btw, Comodo customer support is rather nice. We recently bought a code signing certificate from them and they walked us through the whole process via chat, worked quite well and we were done in about 30 min.
The flaw basically being that people aren't trustworthy, yes?
Do you have any alternatives? There's ssh's model, where you just hope it's the right certificate the first time; or maybe mob-source it like WoT?
There is also an idea to use proof of work to estabilish network-wide consensus about valid certificates (like bitcoin or namecoin blockchain). This would be fully decentralised solution.
Symantec’s family of dominant SSL brands includes VeriSign, GeoTrust, Thawte, RapidSSL and TC Trust Center.
They own about 70% of the certificates, all priced differently to give you an illusion of choice. So if one provider is crappy, their support is the same; and thus they are all crappy.
Except that SSL isn't just about transport-layer security, it's also about identity. The entire model of SSL breaks down if anyone can buy a certificate for anything.
The only reason why I want to support https is so that customers can confirm who they are downloading from. Ideally, I'd like an EV certificate, but I can't afford that. So I chose a business validation cert. A domain only certificate wouldn't really confirm anything.
(Also, some of my troubles would have been the same with a domain-only cert. The emails with missing links were those for domain validation, and I had to paste the CSR in the management area that was offline...)
If your vendor doesn't do a decent job verifying who you are (and this may or may not mean EV), then browsers won't treat the certificate any differently when it's entirely replaced by someone else either.
This would seem that he was in fact looking to provide "some sprinkles [to] make his customers feel better."
Perhaps not a waste of money, then, if it provided what he was looking for?
The second non-solution would be to configure every domain with self-signed certificates, but then you'd still be sending your clients an untrusted certificate. The only way to truly provide SSL on a shared host is to configure it with a UCC certificate that includes every domain you are pointing at it, or generate cheap/free certificates like StartSSL's for every unique domain and subdomain you listen for.
I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.
Also, it makes me angry how you have all those beautifully designed landing pages everywhere, and as soon as you have ordered, you have to deal with ugly and confusing websites that barely work at all.
Using compression with SSL could make your site vulnerable to the CRIME and BREACH attacks. See...
SSL Gone in 30 Seconds - A BREACH Beyond CRIME [video]:
BREACH Attack (HTTP Compression):
CRIME Attack (SSL/TLS/SPDY Compression): http://en.wikipedia.org/wiki/CRIME_(security_exploit), http://security.stackexchange.com/questions/19911/crime-how-...
I developed my nginx config based on their recommendations:
In his 2010 talk "Everything you need to know about cryptography in 1 hour" (http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...), Colin also recommends limiting SSL use to a confined area.
Amazon does this.
For example, Amazon.com only uses only SSL when you log in, check out, or access "Your Account". Everywhere else Amazon.com uses HMAC request signatures over HTTP, similar to how AWS API requests are signed.
See "Signing AWS API Requests" (http://docs.aws.amazon.com/general/latest/gr/signing_aws_api...)
To Colin and the other security professionals on HN:
* Is limiting SSL still recommended in spite of the trend toward Always-On-SSL?
* What are the current best practices and tradeoff considerations of this approach?
Doesn't this leave you vulnerable to session theft?
Someone else here mentioned SSL stripping, which is another problem, which you can't avoid [with partial SSL] no matter how much you try.
If you're deploying SSL today and you're not using HTTP Strict Transport Security, you're doing it incorrectly.
And while HSTS helps protect against sslstrip, you're still vulnerable to MITM attacks due to issues with the CA system.
See moxie's 2011 talk "SSL and the Future of Authenticity" ( http://www.youtube.com/watch?v=Z7Wl2FW2TcA)
The robustness of the public CA system is a legitimate problem, but it's not a concern for most of us. People like to complain that the public CA security model is not perfect, but we have to remember that the CA ecosystem was not designed for perfection; it was designed to enable ecommerce. We now have different goals (well, some of us) and have to change our approach accordingly.
MITM attacks using fraudulent certificates are very costly and make sense only against very high-value properties. If you're legitimately worried about them, you should consider using public key pinning, which effectively deals with the problem. (But, alas, only works in Chrome today.)
In my experience, most people are recommending partial SSL because they're not aware of the security issues. For example, many developers "know" that you're supposed to use SSL only to protect login credentials.
My main concern about a scheme like this is the vulnerability to SSL stripping.
I'm not sure what you can do mitigate it apart from have SSL on all the time, HSTS telling the browser that it should be using SSL and hoping that the first time a user comes to your site is via a https link.
But I'm not quite sure what I need to do to make it better?
the big one is you need to remove the following cyphers:
and disable sslv2
Yes. It's a major vulnerability discovered in the past few months that significantly weakens the crypto.
Website Describing the attack: http://breachattack.com/
Django Blog Post: https://www.djangoproject.com/weblog/2013/aug/06/breach-and-...
Full Paper: "BREACH: Reviving the CRIME Attack" (http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%2...)
The vulnerability occurs when the cookie is part of the compression payload. Although that does depend on the attacker being able to control what gets sent.
> SSL’s not perfect, but we need to make surveillance as expensive as possible
immediately followed by -
> And hey, bonus: more complete referrer information in Google Analytics
Make up your mind already. Are you against the surveillance or for it? You can't really sit with one ass on two chairs.
The idea of surveillance, in this case, is that no 3rd parties can snoop on your data. If you are actively using a site, it should be under the assumption that they can and will track anything you do on their site.
And Google is what... ?
I agree, though, it is kind of silly, knowing that Google has been complying with large numbers of FISA requests.
# Screw Google...
I mentioned this in a separate comment, but I can use this as inspiration to try out Piwik (http://piwik.org), and see if it can replace Google Analytics.
I use Chartbeat for real-time-y stuff and alerts, which it's exceptional at. I think Piwik may have a harder time replacing that one, but I'll certainly try it.
Also it doesn't say in policy.pdf that you can't use it for banking. It just says you can't have a subdomain with the word "bank" or similar in it. So you could use the free certificate for an online bank, although it's probably not the best idea :)
Please don't downvote me just because you didn't read the terms properly. My comment above was correct.
Class 1 certificates are limited to client and server
certificates, whereas the later is restricted in its usage for
non-commercial purpose only. Subscribers MUST upgrade to Class
2 or higher level for any domain and site of commercial nature,
when using high-profile brands and names or if involved in
obtaining or relaying sensitive information such as health
records, financial details, personal information etc.
One interesting thing about that incident is that Startcom never released a report to state exactly what had happened, which is in contrast with some other hacking incidents they suffered. If what Comodhacker said was true (that he had been able to communicate with the NSM), then they definitely were hacked -- just not critically.
I mean, we're not talking a huge amount of money. Webfaction is $5/month . Still!
A small fraction of Internet users on extremely out-of-date system cannot use SNI. If you need to support those users, you will still have to buy a dedicated IP address. I personally don't bother (if you're running IE 6 on Windows XP, you have bigger problems).
This is a great guide! I did the exact same thing several months ago and am very happy with the result. Enough with the excuses not to deploy SSL!
Pretty much everyone would love to use SNI; site owners wouldn't have to pay for extra IPs, hosting companies wouldn't have to worry about securing and allocating them just for SSL use, tons of IPv4 space could be put back into circulation, and CAs would be able to sell many more certs. Unfortunately the group that can't use it is too large to ignore, so none of that's happening.
And dedicated IPs for websites are extremely expensive.
It doesn't need to be this way - Linode gives extra addresses for $1/month each (provided valid technical justification, such as the need to run HTTPS).
(There may well be other reasons spinning up additional vpses for each SSL secured site doesn't suit you, but a few dollars a month price difference is surely only being used as an excuse for inaction rather that a show-stopping financial burden - at least for anyone in the top 99% of HN's demographic…)
Read https://en.wikipedia.org/wiki/Server_Name_Indication for more info.
What I'm not seeing is why it's a problem when a host such as DO doesn't allow multiple IP addresses on a single machine.
Is it because you may want to host multiple sites on that machine and use one IP address for SSL?
Oh, nevermind. It's because you may want to support multiple SSL sites on the same box without requiring your clients support SNI. That makes sense.
We really need to just EOL everyone who has a browser without SNI. People like to say that there's still a lot of XP users out there but surely even a reasonable chunk of them are using Chrome or Firefox with SNI support, right?
One caveat is that the free certificate lasts only a year.
Edit: Actually, I just looked... WinXP still doesn't support it with IE, so, actually it could be a big issue still.
SNI is still a no-go on XP though.
Even though this is a perfectly legitimate top-level domain (yes I paid for a real .tk domain, and I fully control the DNS settings just as any other domain — it is not a free web-based redirect domain, which the Tokelau NIC also offers), StartSSL does not let you choose it when requesting a certificate. They have a drop-down of supported TLDs, but .tk is nowhere to be found (and you cannot edit the HTML to submit this domain anyways, it will be rejected by the server). Initially this appeared to be a simple omission, but investigating further revealed it was an intentional decision to not allow issuance of SSL certs to .tk due to "abuse".
Quite annoying to have purchased an apparently legitimate domain, only to discover it is considered "second-class" by certain online services. Now I am faced with a decision to buy another new domain at a more reputable TLD, switch all my servers and services over, or find another SSL issuer which supports .tk. CACert appears promising, also issuing certs for free, but sadly they are not widely accepted by browser vendors. A paid SSL authority would likely issue a cert for .tk, but at this point I'm inclined to not use SSL at all, or stick with my own self-signed certs (I mainly use my server for personal services, so wide accessibility is not a major concern, but having a "real" trusted cert would be nice).
Does anyone else have any experience with acquiring SSL certs for less popular TLDs? I picked .tk because a short and easily recognizable domain was available, got in before many of the better names were snatched up as in .com, etc, but perhaps giving in and buying a longer domain name at a popular TLD is worth it if it means StartSSL and other services will consider it more trustworthy.
If not, than this is exactly what we need to establish HTTPS as the new standard.
The cheap certs only offer domain verification; in other words, they verify that the person holding the certificate owns the domain in question. Typically via an automated email to one of the contact addresses associated with the domain. The catch here is that you're only allowed to fill out the CN= (domain) field in your cert; the others are blanked out. For what most people use SSL for, that's sufficient.
The more expensive certs will go a step further and verify the identity of the entity or person holding the certificate. This entails things like checking your articles of incorporation if your'e a business; things that tend to require a human operator at the CA reviewing your submission. In return, you get to fill out more fields in your certificate. However, nobody ever looks at the details for certs, so this is pretty much wasted money, IMHO.
The only point at which the more expensive certs get you something of value is:
1. You pay to get a wildcard cert, which lets you use your cert on as many subdomains as you want. If you actually need it for technical reasons (e.g. you let users create their own subdomains), this might be worthwhile. Most folks won't need this.
2. You pay to get an "Extended Validation" or "EV" cert, which gets you a little green box in the address bar with your company name. There's strict requirements on identity validation to get these, and it's supposed to engender more trust on the part of users. They're also very expensive. Personally, I suspect nobody really cares about these and it's just a racket for the CAs. But opinions vary.
It also drives me nuts that browsers still class self-signed certs below normal (non-ev) certs when they basically offer the same level of guarantees (in terms of "this person is who they claim to be")
That said, there are many ways in which browsers could improve the handling of self-signed certificates. For example, having a Convergence-like system to fall back to seems useful. Another possibility would be to use opportunistic encryption, where all access is encrypted even without a certificate. (This would defend only against passive attackers, but it's better than no encryption.)
They should be alright for most stuff, especially for personal use.
And they're free because it costs them nothing to issue them.
 - https://forum.startcom.org/viewtopic.php?f=15&t=1802
The first sentence and a half of this paragraph from https://startssl.com/policy.pdf expressly forbid it. Its final "when" clause might be trying to limit what is forbidden, but, grammatically, it has no power to restrict the first sentence, and doesn't properly restrict the second sentence either.
 "Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc."
(Naturally, I hope I've misunderstood their policy.)
We tried to switch our site to https only recently, and had to backtrack because of this (and because we are too cheap/stubborn to buy an SSL cert from someone who is in the XP trusted root certs).
Those aren't horrible trade offs tho, but yes, those are limitations.
Use a different port number.
https://example-domain.com:12345/ is a completely different website from https://another-domain-on-same-ip:32412/.
No need for a dedicated IP address. No need for wildcard certs, SNI, or any of that fancy stuff. Sure, it's ugly. But it works with every browser (even IE6), and it's not like anybody is actually going to type that into an address bar. You'll be redirecting your HTTP website to your HTTPS website anyway, aren't you?
You can only have two of the following three: (1) shared IP, (2) pretty URLs, and (3) legacy client support. Choose which two you want to have.
I know it's pure paranoia, but this would seem to be an excellent way to compromise a lot of SSL traffic if you were into that, and the Israelis are pretty famous for all kinds of spying activity that makes PRISM look tame. Just curious what others think about this?
StartCom passed an outside audit and is included in most modern browsers by default, indicating that they at least trust StartCom.
They charge for the work they have to do. So, EV and identity validation cost money. Most "domain validated" certs are basically no work, as you can see from the incredibly cheap prices other SSL vendors offer them at.
There are about 100 root CAs, and something like 1000 CAs if you include intermediates (controlled by ~650 different organizations - https://www.eff.org/observatory), and browsers trust ALL of them. All it takes is one to issue a malicious cert, or to get hacked, to do a MITM attack on ANY domain without showing a browser warning.
The trustworthyness of a single CA doesn't make a difference, because if any CA isn't trustworthy then an attacker can use them instead the other ones. This is the problem with CAs, and the problem with centralized trust systems in general. There are hundreds of weak points.
But also, StartSSL does fairly thorough identity verification. I've had to send them photos of my passport and talk to them on the phone to do identity verification. It's also worth noting that it's the CA that both https://www.eff.org/ and https://pressfreedomfoundation.org/ use.
As long as there's a broken CA system, the choice of CA does not matter in the slightest as long as it's trusted by browsers. Users only care if it breaks a website with a scary warning, but if it doesn't, it doesn't matter. There's no need to spend money.
StartSSL does charge if you have more than very basic needs, like if you want multiple alt names, or if you want a wildcard. But it's still cheaper than the competition.
We had endless problems with StartSSL on mobile browsers. They have only recently been added to the latest Windows Mobile 8 repo and you can forget about any phone OS (except iOS) that was released before 2012.
The thing with SSL providers is most people think if it works on Chrome and IE they're set, but for certain businesses they need something that will work on the Wii Browser, an IBM Power System, or an older dumbphone. SmartTV's in particular are pretty annoying to get any CA list because whoever implemented the browser portion on the devices probably just imported some random Java lib from circa 2002.
If you are doing something small and personal, StartCom is just fine. If you're running a business, at some point it may become inevitable that you switch to oldest provider you can reasonably sign up for, in particular one of the Original Three (Thawte, GlobalSign, or Verisign). If you're running a non-profit advocating for privacy and cryptography where a large number of your users may be based in the middle east running on legacy hardware, you may want to take a cursory look to see if your users are getting any cert problems and get a cert from Thawte (the cheapest of the three - though you will need to chain to an intermediary cert if you got with their 123 option).
Now then again, it dosn't matter if you trust them or not, because your browser trust them for you. using another provider will not make you have a better trust in the sites you browse.
Any of the providers can compromise everyone elses trust, as long as they're trusted by the browser.
And thats why the current SSL trust scheme sucks, by the way.
And to further your paranoia, the NSA and Israeli intelligence orgs have form on doing each others dirty work.
But what that really points out is the brokenness at the heart of the PKI system as it's currently implemented.
When was the last time you audited your browsers trust store?
There are higher levels of validation - "business validation" usually involves faxing someone copies of various government supplied paperwork and receiving phone calls on publicly available phone numbers (which is just "outsourcing the identity guarantee" to yellow pages or Dun and Bradstreet.) "EV" validation ( for "green address bar as well as padlock icon" security requires all that plus spending lots of money.
Plus he was going for validation, which isn't free and is a pretty obnoxious process regardless of who you go with.
On issue I did run into (not relevant to the article but anyway) was that Heroku charges $20/month to use SSL on a custom domain.
Long story short: I recently moved my e-mail from Google Apps to a machine under my control. As part of that project, I "redeemed" an unused SSL certificate I had purchased a while back for Postfix and Dovecot.
(While I paid for mine, you can use a self-signed one and most MTAs won't complain or refuse to deliver mail, if memory serves.)
I also wonder if advances in DNSSEC will help eliminate various SSL cert dealers: if you have a secure way to prove that example.com translates to a given IP, and DNSSEC could distribute the public cert for HTTPS in some standard manner, then CA's have no reason to exist anymore. See http://blog.huque.com/2012/10/dnssec-and-certificates.html for a decent discussion of this.
Edit: even better, if I could provide a secure way for you to communicate with my site over HTTPS without relying on a CA, I could also provide you my public GPG key securely. That way you know that firstname.lastname@example.org really has the certificate with ID DEADBEEF. Of course you don't know that I am Igor Partola is who claims to own igorpartola.com, but at least you can securely associate the email address with the GPG key, which is good enough if you, let's say, only know me as my online identity and only care to communicate with me about things related to that identity.
For example, if you found a project of mine on GitHub, and found a huge security flaw in it, you might want to securely email me an exploit and a patch without advertising the vulnerability to the world. It's good enough to have the email/GPG key association without needing to authenticate my real-life identity.
The site authentication private key and the S/MIME private key, however, are always generated in the user's browser.
From my experience (on OS X), if you want maximum flexibility for selecting your S/MIME key size, the browser you should use is the last pre-Chromium release of Opera. It allowed me to select 4096-bit RSA private key and SHA-256 hash algorithm, whereas Firefox, Safari, and Chrome have no option greater than 2048 bits.
It's interesting, I did switch to HTTPS for all my sites but Google Search still did not reveal search keywords to Google Analytics from users logged in at Google. If that's what was referred as "referrer information".
Did anyone get lucky with getting 100% of google search keywords after switching to SSL?
Google search queries/keywords are a different issue - Google is intentionally making it impossible to see most of those (presumably, they've got a plan about how to sell that information to marketers using Adwords…)
I had this same question on a yesterday's thread: https://news.ycombinator.com/item?id=6438992
Basically, using Cloudflare SSL is good for protecting your customers from eavesdroppers on WiFi, not so good for protecting against NSA surveillance. But it's probably better than nothing.
Somebody should go through the top 10k websites and make a list, then repeat every few months.
E.g. http://en.wikipedia.org/wiki/Hacker_News redirects to https://en.wikipedia.org/wiki/Hacker_News .
1. Encryption: protects from eavesdropping (e.g. your internet provider can't see what you're communicating)
2. Authentication: protects from MITM (e.g. someone changing the data en-route)
For full security you need both; but #2 is much more complicated than #1 because it needs a trusted third party, certificates, etc. It's effectively a barrier to having everyone use encryption.
Why isn't it possible to opt for only #1? It should be as simple as adding "Encrypt +All" to your apache settings.
Which is why encryption without authentication is pointless (or, worse, illusory security) in most cases. On the internet, your communication is inherently being handed off through a number of intermediaries to an endpoint. If you don't know who the endpoint is, it doesn't do you any good to know that your connection is secure from you to the endpoint.
I really, really dislike the CA cabal. Self signed "encrypt only" certs combined with auto cert pinning in browsers would probably solve 99% of the problem.
Nobody likes the CA problem, but you can't handwave the problem away.
TACK (which provides auto-pinning) is hopefully going to be a solution to the lack of trustworthiness in CAs, but TACK's deployment model also presumes a CA infrastructure.
(The "locks on doors" argument.)
My original point is twofold:
First, having encrypted/unauthenticated communication is still better because it takes more effort to intercept, while doing so for unencrypted/unauthenticated is trivial (e.g. Google's WiFi sniffing debacle).
Second, encrypted/unauthenticated can be implemented to be almost completely transparent (for example, server and browser do a key exchange on every request; kind of how gzip compression is automatic), whereas encrypted/authenticated requires certificates (which you have to pay for, renew, copy on your server, etc.).
Right now X% of sites use HTTPS and (100 - X)% don't. It would be best if 100% of sites used HTTPS. But using _some_ form of encryption for the (100 - X)% is better than nothing, and more achievable than saying "encryption-only is useless, everyone should use authentication as well".
(I can't find any stats for HTTPS usage, hence the variables.)
You can opt for only #1, but virtually every browser will put up gigantic warnings about it because it's indistinguishable from a MITM attack.
We have client-side signals for those things. http means unencrypted, https means encrypted. To do encrypted-but-not-authenticated, I guess you'd need a third URL scheme for it, to know when you're supposed to get that, since you can't shoehorn it into https safely.
If I enable SSL on my website do you think I will be able to get the referring keyword from Google? Now that Google is making all searches secure about 80% of the searches show up as 'Keyword Unavailable'. http://searchengineland.com/post-prism-google-secure-searche...
 SNI - http://en.wikipedia.org/wiki/Server_Name_Indication
The SSL connection is set up before the HTTP request is sent; that's why the dedicated IP per domain is required, since the domain (Host header) is part of the request as well. The URL you're accessing is not sent in the clear.
And on some networks, the content of news articles that we might think of as totally innocuous is considered very sensitive, and the network operator might try to block it. The most familiar example might be news about annual commemorations of 6/4. Using HTTPS provides resistance against content-based censorship because the network operator doesn't know when users are reading the specific things that they wanted to prevent them from reading.
So how do you know if the content you're reading has not been tampered with? You don't, unless the connection is encrypted.
If you're going to install a new root certificate on all your client machines, you could just as well generate your own CA inside your organization and do the same thing without trusting some third party.
(Edit: I think I've been trolled.)
"Self-signed certs as a service! IN THE CLOUD!
Need Support for your self-signed cert? 5k/year - 1 (800) 555 - 5549"
I wonder if they have an affiliate program
If you'd rather use the Java Keytool to manage your certs, I wrote up this guide on making it work with StartSSL. https://buddycloud.org/wiki/buddycloud_SSL_setup
Should just be a copy paste, wait, paste, export job.
Compounding this, the configuration file formats for each web server platform vary wildly, selecting the correct format and installing it properly can be tricky.
Making matters worse, it's very easy to set up something that looks like it's working, but is actually broken on some subset of the browsers out there.
These problems can be solved with better standards, better documentation, testing tools, and most of all, providers that actually care about the user experience they're selling.
You can set up your own CA but you can't sign for domains unless you're in the proper chain. The ones holding the keys for these are the big providers.
I see a potential vuln here for free e-mail services. If one manages to register one of those addresses he can create a trusted certificate and use it for MITM.
It also highlights a critical SSL issue; there's really little strength in the concept of a certificate proving the identity of anyone.
In testing, we found that DigiCert was 50-100ms faster on queries than our existing GoDaddy certificate, based on the location of their CA hosts.
The improved response time resulted in a 15% increase in traffic on our API.
I've been using these since 2011 (starting with one year certs before switching to 3 years later) with no problems.
 Ex: https://ianthedeveloper.com
But what they ought to do is to accept the self-signed certificate, show something other than the usual lock icon but do the encryption anyway, and then freak out if the certificate changes before it expires.
HTTPS with self-signed certificates is better than moving plaintext over the wire, in the same way PGP is better than moving plaintext over the wire. It doesn't matter that you don't have a "trusted" peer to tell you this PGP signer is who it says it is. As long as you can trust you acquired his key in a secure way (e.g., out-of-band), it's better than the alternative.
Plus, MITM concerns over self-signed certs are moot. This vulnerability exists at the DNS level anyway.
(b) Why? I understood they were among the better providers.
My Safari can't verify the identity of that website. This is Safari 5.1.7.
b) I simply don't trust them, particularly since they use a keybased auth system -- any compromised computer that was used to setup a startcom cert can download the private keys
b) I think it's moot whether this is better or worse than a password, but I'd probably pick the key-based system (which requires you to physically have my computer) over a password-based one (which might be hacked remotely).