Hi kajarya! Well, for once, we're only displaying a discount for committing yourself for 12 months, that's fair, wouldn't you agree? Furthermore, neither Slack nor Hipchat are available for fee if you want to use it at its full potential.
Most importantly, with ChatGrape we're going beyond of simply providing a chat based communication solution. On ChatGpape, we're offering a smart engine that automatically triggers workflows based on your communication, such as, let's meet at 2pm tomorrow - automatically adds a calendar event.
There's more than that, of course, but the essence is that we're running a quite extensive engine in the background to make your team's communication easier and more efficient, and that takes up actual processing power.
Finally, considering that our aim to to save you time that you can use better on building your own baby, instead of wasting time searching for documents you ant to share and issues you want to reference - the average startup using ChatGrape has access to all the features for around 35 bugs per month, which is really a reasonable price, don't you think?
Glad that you ask! Let me explain. In fact, "automatically" is actually a bit misleading. The correct term must be "half-automatically", because everything triggered within ChatGrape still requires your confirmation. (If not, we'd be flooded with false-positives.) Think about tagging on Facebook, specifically, writing a status update and tagging a page of a friend. If you start typing his / her name, Facebook will add a drop down menu and suggest the name(s) - you can select it or choose to ignore it - and the drop down will disappear again. This said, if you were to type, "No, 11am is not good for me. [first drop down with calendar event suggestion, which you simply ignore and go on typing] let's meet around noon tomorrow?" [second drop down with calendar event suggestion, which you confirm, and thus send me a calendar event invite]. Does this make sense?
If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.
If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?
First, it requires more than just a request flag, since that flag only affects the signature algorithm in your certificate signing request. Your certificate authority has to actually support signing certificates with SHA-2, and also needs a chain that uses SHA-2 signatures. There are some certificate authorities that are lagging behind here, such as RapidSSL.
Second, there are old clients out there that still don't support SHA-2. Namely, pre-SP3 Windows XP and pre-2.3 Android.
Edit: originally this comment said that only IE on pre-SP3 Windows XP was affected; apparently Chrome on pre-SP3 is as well, presumably because it uses some system libraries.
Just curious — does X.509 support multiple signatures, so both SHA-1 and SHA-2-based sigs could be included, one for legacy user-agents and one for modern ones?
Lots of old clients still out there, including people who don't have the option to upgrade.
A couple of years ago we tried upgrading our certificate to SHA-2, and rolled it back within an hour, because it broke the site for several of our customers.
It might work now; IE6 users have (finally!) dropped to about 0, but we certainly have tons of IE7 users, and I'll have to look up versions of Windows they're using before we try it again.
We work with hospitals whose IT departments who need to control changes to their computing environments extremely carefully, and upgrades are unfortunately quite expensive and difficult for these kinds of environments.
Fortunately, hopefully most enterprises moved to SP3 years ago. MS officially dropped XP SP2 support in mid 2010, and while MS does do Custom Support for older service packs, of course I hope no one is relying on it now. I think Custom Support for WinXP SP3 is IE8 only after the first year BTW.
My company website is one of the only ones I tested that actually passed. At first I thought there was simply a shocking lack of adoption, but based on this thread, seems like there is some level of "wow, this is nowhere near as common as it should be," and some level of the tool being somewhat overly strict on what passes.
Either way, Google has made it pretty clear that they want at least SHA-2 certificates, which, so long as they call it out in address bars, warning interstitials, and make noise about SERP impact, means that this is the way things are going.
You have it kind of backwards. Not these sites or their certificates are vulnerable, but the certificate signing process itself is. And by extension all browsers that accept SHA1 certificates anywhere are. To clarify, what the attack does is generate two certificates that have the same SHA1 hash, one of them legitimate and one of them illegitimate. In the worst case scenario the illegitimate one is an itself an intermediate CA, which means the illegitimate one can MITM any connection. You send the legitimate one to the CA to get it signed. When you get it back you swap the legitimate certificate with the illegitimate one - which is possible as both have the same hash - and voila, you have broken TLS world wide.
Having a certificate with SHA2 will not save you. A client under attack will not even see it. The only thing that helps is stop accepting SHA1 certificates (and especially SHA1 intermediate CAs) globally. All this stuff about accepting short lived certificates is only a publicity stunt by Google to raise awareness about the issue (an attacker can forge a certificate with any expiry time she wishes).
Someone on HN knows this subject much better than I do, but as I understand it, there's no attack in the literature that takes a good certificate request and $2MM as an input and spits out a validating certificate as an output.
This is different than the situation with MD5, where the components needed for a successful attack were known to the literature, and the real work was (a) scaling the attack so that it could perform within the time windows needed to forge a TLS certificate and (b) putting all the pieces together.
(But see upthread with 'pbsd, who is one of those people on HN who knows the subject much better than me).
The SHA1 vulnerability being contemplated here affects only the establishment of an HTTPS connection; the attack scenario involves obtaining a forged certificate.
It is, you're right. It's a hobbyhorse of mine, though, because SHA1 (and MD5) appear in TLS ciphersuites as MAC components, and those uses are not known to be vulnerable at all.
