When you see an incorrect/misleading answer, the first thing to do is to downvote and preferably to add a comment. If someone has already left a comment for this, upvote the comment itself.
Beyond that, it can be tricky and may have to be handled on a case by case basis.
I think the biggest problem with this is that it seems some users tend to up-vote the answer that already has the highest score, even if there are more correct answers around.
I've noticed this in this question, asked in Sep 2009. The most highly upvoted answer (until March 2012) was incorrect.
- I downvoted it and left a comment in Sep 2010.
- Some people kept up-voting it, so I left another comment with more details in Dec 2011.
- Later, I noticed that people kept up-voting it, so I took the time to write a much longer answer (with references). It started to be upvoted a bit and eventually caught up with the incorrect answer.
What I've noticed is that the incorrect answer still got a few upvotes during that period. It was clear that those up-voters had not gone much further than this incorrect answer (still at the top of the list per vote count at the time). My guess is that my answer was "rescued" from being unnoticed by the fact it's rather long and has a fairly large number of references. It seems quite hard to break out of that "up-vote the answer with the highest score" pattern otherwise, unfortunately. (I should point out that the asker hadn't accepted any answer at the time, and that the author of the incorrect answer never replied to any comment. I'm not sure whether those questions were semi-abandoned.)
Another thing that can help, if you've exhausted the approaches above (i.e. downvote, comment and write a better answer) is to draw attention to it on Meta. It's not quite what Meta is for, but for clearly incorrect cases, it's worth a try. (I would seem that the "publicity" coming from a discussion on the closure/rewording of that question led more visitors to it.)
I'm not entirely convinced that flagging or asking for moderators to sort it directly is the right approach. I'd still prefer there to be a discussion on Meta beforehand, simply because re-arranging the accepted answer forcibly goes again the principles of SE, even if it's for the right reasons.
In addition, even high rep users and moderators can be wrong sometimes. No one is perfect. I'm going to illustrate this with an example. I apologise in advance to voretaq7: please don't take it the wrong way, I'm only picking on this particular answer of yours, which is incorrect; I know that the vast majority of your answers are usually correct and that you deserve your high rep. This is unfortunately one of those instances where the incorrectness was pointed out in comments (even in this question).
The currently accepted and most highly upvoted answer to this (canonical) question is mostly incorrect; it was completely incorrect to start with, but has now been altered to add a correct link, leaving the incorrect parts unfortunately. Since a bounty was offered on that question a few weeks ago, a complete and correct answer appeared, although it's not yet the most highly upvoted.
(In my opinion, the best course of action would be for the author of the incorrect answer to delete his own answer, there would be a slight loss of rep, but negligible out of 40k+, and he would win the Disciplined badge.)
Now I need to justify what's wrong with this answer... (In fact Meta is probably a slightly better place for this, since comments don't give enough space unfortunately.)
The question is about what can make multiple certificates on the same IP address and port for a web server with SSL.
- The answer (since its first revision) talks about RFC 2817:
"Multiple (different) SSL certificates on one IP" is brought to you
by the magic of TLS Upgrading. It works with newer Apache servers
(2.2.x) and reasonably recent browsers (don't know versions off the
top of my head).
RFC 2817 (upgrading to TLS within HTTP/1.1) has the gory details, but
basically it works for a lot of people (if not the majority). You can
reproduce the old funky behavior with openssl's s_client command (or
any "old enough" browser) though.
While upgrading to TLS on the same connection could solve this problem, this is not how HTTPS works. HTTPS is HTTP over TLS (RFC 2818), not RFC 2817.
HTTPS (as used by user-agents connecting to an
https:// URL) always initiate the SSL/TLS connection first.
RFC 2817 is widely unsupported. No browser support it (see Chromium issue 4527 and Firefox issue 276813). There are some good arguments against using it (mainly because it's hard to convey the fact you need to turn on security afterwards by just having a URL, whereas
https:// does it well with RFC 2818).
The only software I've heard of that uses RFC 2817 is Cups (the printing system). Even if Apache Httpd has had support since version 2.1, it seems to have been buggy since version 2.2.9, at least with
OPTIONS *, without which you would have to send the initial URL in clear, before the upgrade. RFC 2817 wasn't supported more in 2010 or in 2000 than in 2012.
openssl s_client has some support for protocols that upgrade within the application protocol (the "START TLS" way), HTTP and RFC 2817 isn't one of them. As the help says: Currently, only "smtp", "pop3", "imap", "ftp" and "xmpp" are supported.
A subsequent revision adds some curl debug traces, using
-1 (for using TLSv1) and
-3 (for using SSLv3), possibly to try to justify that upgrade story.
Unfortunately, neither of these debug traces show any HTTP traffic at all, they only show the SSL/TLS handshakes. RFC 2817 is a protocol that relies on an explicit HTTP
Upgrade header, in an HTTP request. This isn't there.
In both cases, with SSLv3 and TLSv1, the HTTPS connection starts with establishing the SSL/TLS connection. No upgrade takes place later on.
The real reason why this is happening is that TLSv1 has been extended with a
server name (SNI) extension (see RFC 3546), which came after the TLS 1.0 specification, and was never back-ported to SSLv3.
curl, both TLSv1 is enabled, which also makes it use the SNI extension if it was compiled with a recent-enough version of OpenSSL (OpenSSL 0.9.8f with specific compile-time options and OpenSSL 0.9.8k by default, according to this).
That extension is part of the Client Hello message, and the curl trace doesn't show any of its details, thereby making the traces irrelevant without the explanations I've just given (and misleading when connected to RFC 2817).
A later revision finally adds a link to SNI (in the context of Apache Httpd), which is the only correct part of that answer. It's just unfortunate that the rest of the answer wasn't removed. SNI is something that happens in the initial Client Hello sent by the browser, not something that's upgraded later.
The issue is that the answer's author seem to confuse SNI (the TLS extension defined in RFC 3546, later integrated with TLS 1.2, which is purely a TLS mechanism) with the protocol upgrade as defined in RFC 2817 (which requires some HTTP application protocol messages to be exchanged before the socket is upgrade to SSL/TLS). Coming from one comment on that answer:
Re: apache and SNI, Apache (2.2.x) definitely supports SNI, and should
support TLS upgrading (it would probably depend on the version of the
SSL library you're using though - something you should test on your
specific installation). Specifically allowing only "strong" encryption
via your SSLCypherSuite rather than have the client renegotiate the
connection's encryption is definitely preferable though.
Again, TLS upgrading has absolutely nothing to do with what happens with SNI. Granted, SNI only works with TLSv1 or above, but the SSL/TLS version (3.0, 3.1, ...) is negotiated from the start when using HTTPS, there's no "upgrade" going on. RFC 2817 is enabled with Apache Httpd by using
SSLEngine optional; how many of us have ever used "
optional" there, really? Since it's not supported by browsers, what would be the point anyway? Unlike SNI, RFC 2817 support doesn't depend on the version of OpenSSL used with Apache Httpd.
Perhaps some of this misconception comes from the eternal confusion between SSL, TLS and "START TLS" (where the key word is "START", not "TLS")...
Apart from 3 lines at the top, that answer is misleading and/or incorrect. Yet, it's the accepted answer with 36 upvotes and 2 downvotes.
In short, when there's an incorrect accepted/highly upvoted answer, once the downtvote+comments approach has been used and has failed, discussing it here on Meta is probably the way to go.
As for the particular answer I was using as an example, its author quotes RFC 2817, which is in fact virtually never used, at least not for HTTPS, and confuses the "TLS Upgrade" defined in that RFC (which requires some plain-text HTTP exchange first) with Server Name Indication. He also seems to confuse TLS, (the version of SSL/TLS following SSLv3) with the common mechanism for upgrading from plain-text traffic used by other protocols often known as STARTTLS. Indeed, he seems to assume that the behaviour is different with SSLv3 because TLSv1 does an "upgrade", whereas it's because TLSv1 has support for the SNI extension when SSLv3 hasn't: in both cases the HTTPS connections are initiated with an SSL/TLS Client Hello without any RFC 2817 upgrade.
Despite multiple comments, that author hasn't done anything about it, which is a bit at odds with his own answers to this very question.