Potentially a simple addition of 6697 to kRestrictedPorts 
https://cs.chromium.org/chromium/src/net/base/port_util.cc?q=krestrictedport&sq=package:chromium&l=22

I can't reproduce the problem.

* Chrome sometimes can't negotiate a sufficiently-good/-modern ciphersuite with irc.freenode.net.

* Other times, the server asks for a client certificate. I just click Cancel, and the connection seems to go through anyway.

* Firefox has not (yet) exhibited the ciphersuite problem, but it also gets asked for a client certificate.

Screenshots of the results in Chrome and Firefox are attached. I didn't see the "hi" message in the #xps channel on freenode.

However, I am entirely willing to believe that with more work, the attack would work/the message would get through.

I am pretty sure that just putting port 6697 in kRestrictedPorts would not really solve the problem. If (for example) botnet masters wanted to use your browser as a vector for some kind of attack, they would just run their IRC server on some other port, possibly even 443.

I also don't see what's TLS-specific about this — wouldn't this work over plaintext IRC, too? (Or at least, is there any fundamental reason why not?) Currently, both Firefox and Chrome block port 6667, but that's not a *fundamental* reason.

The 'real' fix, to the extent that there can be one, would be for the IRC server that wants to protect itself from spam from HTTP clients to be more strict in what it accepts. Currently, the body of the HTTP request looks like this:

===
x=
USER a123vmdfhliinzv 8 * :mwixqbd
NICK a123mwixqbd

JOIN #xps

PRIVMSG #xps :hi
===

The IRC server should (a) reject things that don't start with the USER message, including the "x=\n" but also the HTTP request headers.

Of course, the hypothetical botnet masters who *want* to receive such messages could still run a server that tolerates them.

So it seems there are 2 attack scenarios:

1. Spammers who just want to induce innocent bystander HTTP clients to flood/troll/spam/annoy the users of a tolerant IRC server, or to even attack some weakness in the IRC server.

2. Botnet masters, who can run a server of their choice, and who are using the innocent bystander HTTP clients as vectors for C&C messages or to send in additional information from the client, such as form auto-fill stuff. But, these attackers could just as easily use a real HTTP server; there's nothing special to their attack goals about IRC, per se.

Deleted: firefox-xps.png 20.4 KB

	firefox-xps.png 20.4 KB View Download

Deleted: chrome-xps.png 25.7 KB

	chrome-xps.png 25.7 KB View Download

palmer: I'm not sure how to reconcile your conclusion with your concerns about the solution in comment #1 (which I agree with Eric, seems sensible).

As you note in the two threats, we can't do anything about #2, and while #1 is arguably a server-side fix, it does seem that adding it to the restricted ports (as in comment #1) mitigates the most common form of cross-protocol attack damage.

I think the threat model here, much like SMTP attacks, has to assume "Given servers that exist on the Internet and do nothing to mitigate this issue, what can or should the browser be expected to do" - and #1 seems like the reasonable line?

Or are you thinking we should do nothing? That's what I was confused about.

#3: I don't think it's a solvable problem, and so would be OK with doing nothing. My usual fear that mitigations (like blocking the port) will be mistaken for solutions kicks in: the perception that a band-aid is a cure can be worse than the disease. :)

That said, blocking the port is highly unlikely to break any real applications, it might even slow down some real (low-skill) attack, and we already do this class of mitigation, hence we might as well do it here.

I agree with comment #3, it is straightforward and consistent to add 6697 to the restricted port list, despite its limitations.

Does this bug warrant having security flags? This isn't what we normally consider a browser vulnerability.

No, I don't think we need to keep this secret.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ba78b86d7b4ef5140ef9838d41ca471b3075ef32

commit ba78b86d7b4ef5140ef9838d41ca471b3075ef32
Author: palmer <palmer@chromium.org>
Date: Thu Dec 29 21:47:20 2016

Block communication to port 6697 (IRC over TLS).

BUG= 676951 

Review-Url: https://codereview.chromium.org/2607963002
Cr-Commit-Position: refs/heads/master@{#440987}

[modify] https://crrev.com/ba78b86d7b4ef5140ef9838d41ca471b3075ef32/net/base/port_util.cc

Don't I get a bounty for this? That was the reason I reported it.. 

#11: Unfortunately, this bug does not qualify for our vulnerability rewards program, for the reasons discussed above. For more information about what kinds of bugs qualify, please see our Vulnerability Rewards Program information page:

https://www.google.com/about/appsecurity/chrome-rewards/index.html

Thank you for your prompt response.  I read that before submitting and the discussion above, but I'm still not clear on the reasoning.  This is the first Chrome bug I've submitted, so sorry if my inquiry seems kinda nubish.  Please clarify cause I don't like giving away bugs for free. 

Yeah, I was sorry to have to disappoint you — we love getting vulnerability reports, after all, and want nothing more than to pay a bounty for them. But, in this case, the reasoning goes pretty much like this:

https://www.chromium.org/Home/chromium-security/security-faq#TOC-Are-XSS-filter-bypasses-considered-security-bugs-

Like the XSS Auditor, the restricted ports list is a best-effort attempt to mitigate bugs that are really bugs in the server. If an IRC server accepts an HTTP POST as a legitimate IRC message, that really a bug in the server software: why is its parser so tolerant? (And, should IRC include some kind of CSRF defense? And so on.) Chrome (or whatever other client software) would merely be the vector, but not the root cause.