I really don't think there should be a way, frankly. This shouldn't be tested from a webapp.

That's actually a huge annoyance of mine. There's no stable, cross-platform web API to get raw sockets, and I'm not sure why.

Imagine if every webpage (JavaScript) could open sockets to any location and port - sounds like a significant security issue.

They essentially can via the WebRTC api, albeit in a more cumbersome way. There's nothing inherently insecure about it and the onus rests on the serving party and the browser itself to ensure no foul play is happening.

Doesn't WebRTC have a handshake protocol to ensure that the other end expects the WebRTC media stream?

If you allow a browser to open sockets to random places, it's the exact same principle! The onus is on the listener to ensure that the people communicating respect the agreed upon protocol.

Then every browser could be used to send spam. It would be horrible. Imagine that every person who visits a compromised page immediately started sending spam emails over smtp. Or spam irc messages.

Flash could do that, and yet I've never heard of it as a problem.

Generally is not a problem, as Flash needs to check a file called "crossdomain.xml" that is served from the destination server, which specifies how Flash can communicate with it.

http://www.adobe.com/devnet/articles/crossdomain_policy_file...

WebRTC uses DTLS, not TLS, so I don't think it would be useful for determining TLS compatibility.

Yes I'm aware (WebRTC actually uses DTLS, SCTP, RTP, RTCP, ICE, STUN, etc depending on what it's doing). My point is about the objection against being able to "open sockets" in the post I'm responding to...

Being able to "open a socket" kind of implies you actually get the socket, not just "Oh, if the far end negotiates the protocol we've pre-agreed then you can also send bytes over it". Web sockets "open a socket" in the sense WebRTC does too, but of course that isn't what you want either.

Only Flash actually has an API like BSD sockets where you can do make TCP connection and send an arbitrary protocol over it. Hence, since they want to test protocol compatibility, they used Flash. Doubtless if Flash didn't exist they would provide a handy Python program or something, and 99% of visitors would never run it.

The obvious solution would be to ask the user for permission before opening the socket.

This is always the proposed answer whenever someone wants to introduce X potentially insecure API. It is lazy IMO. It requires the potentially uninformed user to make a critical decision. Plus, if we introduced every insecure-but-we-prompt API proposed, the user would be inundated with prompts and it would reduce their productivity.

Forget impacting their productivity, we've already seen what happens when you defer these questions to the user. They always hit yes or okay. It's like it's not even there, people would view mindlessly accepting prompts like that's just how you're meant to use a computer.

More important than reducing productivity is the problem that prompt-overload conditions people to just blindly click accept.

And yet Flash allows this and it hasn't been a problem for years?

Flash requires you to install a socket policy daemon[1] that typically listens on port 843 (which is why the MITM test requires that port 843 be open). When you request a raw socket, Flash first connects to port 843 and requests the policy file, which will tell it whether it's allowed to use raw sockets with that server.

I've set one of these up before, and I'm not really a fan.

[1]: http://www.adobe.com/devnet/flashplayer/articles/socket_poli...

I just don't get how that's different than anything that's not a webapp

You probably don't run arbitrary untrusted applications on your computer but you execute arbitrary untrusted Javascript all day when visiting web sites. To make this seemingly crazy thing work at all, some restrictions have to be imposed on that untrusted JS code.

How would that interact with the Same-Origin Policy?

Since you wouldn't have access to cookies I don't think it would be the end of the world. However you would have access to the users LAN which would likely make many local devices' vulnerabilities exploitable. All in all it is probably a bad idea with the current state of IoT, home routers, printers...

Giving a web page access to any part of the user's environment not explicitly given to is malicious data exfiltration waiting to happen.

There's this [0] standard that nobody implements, AFAIK the security risks could be mitigated by asking for confirmation from the user.

[0] https://www.w3.org/TR/tcp-udp-sockets/

I'm not sure users would understand what they are being asked. Plus, whenever someone wants to do something dangerous in the browser, they say "Oh, we will ask the user". If everyone got their way, users would be inundated with dialogs.

Raw sockets are not required for TCP protocols, need root privileges and hopefully are not used by flash. Terminology problem?