I have been looking around for a solution that implements this, but google always gives me tutorials on establishing a live chat over an ssh tunnel--not the other way around.
I suspect this can be implemented just using tunnels (if it is possible at all), but I am not sure how.
I am sorry if this has been asked, but after looking through the related questions, but I have not been able to find one that I can be sure will work for my particular needs (i.e. I cannot create an ssh session directly with gmail.com etc.) If I am wrong, please just post a link to the applicable question.
If you can establish connections between peers via your IRC channel, then there is a solution.
Don't try to fiddle with IRC itself, but build a solution on top of it.
Use ssh yourself on top of IRC.
I mean create a SSH/SSL connection to a dummy socket you can use to intercept the data sent by SSH. Transform this data (if necessary) to make it transportable via IRC. And send it to the remote peer via IRC.
On the remote peer, intercept your data, un-transform it before giving it to your ssh/ssl connection listener. And proceed the same way to send response.
If the connection is successful ssh will tell you and your can start pouring your data through this secure 'channel'.
Your data going via IRC will be safe, because ssh is.
Related
So I am looking into building a game using WebRTC, mostly just to learn how to use WebRTC more than anything. What I envisioned in my head was one browser (lets call it Alice) wants to start a game. They figure out their connection information and then send that info to another browser (Bob) who they want to join their game. I like the idea of a link similar to a discord invite.
What I had imagined, was that this was all that was required. Bob's browser knows where Alice is, and Alice is expecting a connection from someone who knows about their connection information (their SDP). Instead what is required is that Bob needs to generate his own connection information (his SDP) and then hand that back to Alice somehow. (For reference, here is an implementation of a "serverless" WebRTC client, which requires both parties to pass their connection info to the other person https://github.com/lesmana/webrtc-without-signaling-server)
Because there are two required messages, telling users to do this manually is very much a pain, and gets increasingly difficult with more users (e.g. Alice, Bob and Charlie want to connect). For this reason we have "signaling servers" which handle this handshaking.
My question is why is all of this necessary? Is it for security? Couldnt you consider a browser secure enough if their SDP info included a generated hash that only those they expect (like Bob) have access to?
Don't confuse connection info (ice candidates) with SDP.
What are ICE Candidates and how do the peer connection choose between them?
If you are asking specifically about web browsers - then yes, you have to collect connection info, nothing to do with SDP, from each browser. This is because browsers do not listen on a specific, well known port, which is open in firewalls too. So it's not like one browser could just connect to another one, using well-known endpoint (IP:Port).
The idea is that Stun server will drill a hole in both firewalls and thus will make direct connection between browsers possible. Read STUN spec to see how this is done.
However, if one peer is a browser, and another peer is your own application that listens on specific port (WebRTC gateways, media servers), then you don't need to collect connection info (ice candidates) from the browser. Nobody needs it. Stun/Turn servers are not involved. Browser always connects to your application. You can hardcode ice candidate in your webpage, which will contain the endpoint exposed by your application.
You always have to exchange SDPs between two peers, because they carry codecs information and other info about media stream, that another peer needs to know about. Browsers need to agree that they can decode the incoming stream, for example.
Well I am studying about Web-RTC from its official documentation. I need to integrate live streaming in my website but after seeing this and studying about all its documentation. I only learn about streaming on locally like on same browser and same page. But this is not what i want. I want to start stream from my admin panel(This part has been completed) and broadcast that stream whoever has access to my website whatever the website is and whatever device. Whoever open my website if i m streaming then he should see that and if some of u have worked on live streaming then u should tell me. It will be a great help for me. All i did until now is to make a connection between two peers on same page. Now i want to make global peer to peer connection
I have done this implementation using simple-peer. Basically a wrapper for webRTC.
As soon as a new user connects a new webrtc connection should be made between the receiver and the caller. The receiver is firstly initialized and then sends a message to the sender to start the connection. This first connection is all done by your own server you should write.
Here is a working example. And here is the demo. Any connected devices will be automatically connected to the call. Multiple users supported. You'll find all the webrtc code in /public/js/main.js
You have to do signaling which mean that you have to exchange the PEER CONNECTIONS over the server and which required you to build a server page and client page so both of you can exchange the peer connection.
here is the complete procedure of exchanging the peer connection over the server.
find the heading
RTCPeerConnection plus servers
https://www.html5rocks.com/en/tutorials/webrtc/basics/
I'm new to WebRTC and I was wondering if it's possible to have webRTC application on a local network without need for signaling since we have the IP addresses of all members on the network and if so how should I use RTCPeerconnectio to create an offer?
Thank you
No it is not possible.
Signalling is for more than just exchanging IP addresses. The clients also exchange information about media types and codecs.
You could possibly do some of the exchange via hard coding. But you would basically need to go through the whole negotiation, logging out all the candidates, offer, and answer. Even then I don't know if it would work the second time (with everything hardcoded). It also wouldn't work if you ever wanted to change media. It would be an interesting experiment.. but probably a huge waste of time.
It can be done! But kradical is right there will need to be some configuration ahead of time check out pion/offline-browser-communication
Here are the things you need to worry about
You don't need to hardcoded IP addresses anymore thanks to mDNS candidates. If you know the hostnames of the two computers they can both change IP addresses, and still be able to connect.
You need to know the DTLS certificate and ICE credentials ahead of time. If you look at the repo I shared you can see how it is done there. I did Go <-> Browser because it is the Open Source project I work on, but can easily be Browser <-> Browser as well.
I would connect with only a DataChannel at first, and then re-negotiate with all the details around media (tracks you wish to send and supported codecs)
I'm playing around with WebRTC, and what I'd like to achive is:
User1 opens the browser at 192.168.x.x
User2 opens the browser at 192.168.x.x
The same page
User 1 clicks call, user2 displays the stream on his screen.
I've created a signaling server with node and socket.io and I'm able to exchange messages betweeen users using socket.io rooms.
The steps I'm following are:
Get User Media
Create peerconnection1 - no ice servers
add the stream on peerconnection
create the offer
send offer via sockets
Receive the offer and create peerconnection2 - no ice servers
sending the answer
I've also put some logging in "onicecandidate" and "onaddstream" to see when they are called, and on "onaddstream" I create the videoelement.
When I press the call button I see on the other computer that the video element becomes black but I dont see any video neither audio.
For sure I'm missing some vital steps,
Could someone tell me the steps I have to do to make a correct call and exchange all the necessary data to display the stream on the other side?
Thank you very much
A STUN server is used to get an external network address.
TURN servers are used to relay traffic if direct (peer to peer) connection fails.
see this image describes how peerconnection works
webRTC Basics
You should still have at least a stun server referenced for one of your ICE servers. I would use 'stun:stun.l.google.com:19302' || 'stun:23.21.150.121', even though you do not technically need one.
But if you do not have ICE servers, you do not need to worry about gathering candidates. A couple of things that could be happening.
Make sure you Add your streams to each connection BEFORE creating your offer and creating your answer, it says you get the user media but not that you add it to your peerconnection
You are not setting your local and remote descriptions
Offering computer should set their local description when creating it
Answering computer should set their remote description with the offering description and set their local description with the one they create
Make sure you send the answer sdp to the initial offering computer and that that offering computer sets it as their remote description.
Streams WILL NOT send to each other unless you add the needed streams, create your descriptions, and then set their local and remote descriptions accordingly.
If that does not work, you should probably post your code for the page.
I need answer to one very basic question.
Is it necessary to have telnet access to hit an API while systems are connected over VPN? For example, if my system exposed an API for other systems to hit and they are connected in VPN using IPsec, does a third party system needs telnet access to my server for using that API? The API uses soap protocol for receiving request and sending response.
(I did not find out the solution using google. The question is so naive that I had to assume everyone must already know the answer and does not bother to discuss it in web. Sorry for bothering with this simple question)
This is very strange. Accessing an http endpoint for anything else than dev using telnet doesn't really make much sense to me. If someone is using telnet to fetch informations from a server in an application. Something is already really wrong. If telnet is timing out while doing http requests. It's not really your fault and you shouldn't have to worry about edge cases like this.
If the dev is using telnet to discover security issues. This is a different issue and you could probably log anything that come from this particular client. If you gave hime some credentials, it should be easy to find who is doing which request. (I believe you might be already doing this).
You should probably ask the dev "why are you using telnet?". If for whatever reason the dev though he could send a plain SOAP request to your server using telnet without sending HTTP headers and so on.... then yes the connection is likely to timeout because the server isn't going to handle the request.
In my twisted mind, I can imagine some kind of legacy application calling scripts that open telnet sessions to parse some data and return the "parsed" data to the patched legacy project that doesn't handle http/tcp. I'd have in mind some sort of old Cobol application. Much more easier to do system call than to rewrite the whole thing to support APIs.
If for whatever reason, the client claims that telnet is needed for whatever reason. You can tell him back that telnet shouldn't be considered secure. Your api can be accessed using https. As far as I remember telnet doesn't encrypt anything unless you send encrypted data. If your client was able to hack a solution using telnet, I'm pretty sure they can hack a different solution wich use an actual http client.