For testing if I am getting the relay candidates, I am using this page: http://googlechrome.github.io/webrtc/samples/web/content/peerconnection/trickle-ice/. To test from chrome 40, I provided my turn url and credentials there. After clicking gather candidates I can see no relay candidates. Doing the same test from firefox 36, I found the relay candidates. What could be the possible problem ? To further investigate the issue, I looked into wireshark log. What I found is, from firefox the stun request format includes-
STUN 146 Allocate Request UDP lifetime: 3600 user: lazy realm: with nonce
But from chrome, this is slightly different-
STUN 70 Allocate Request UDP
It seems the request code is not same. Moreover, request from chrome doesn't include the lifetime, user and realm property.
I know the question is already a bit old, however from my experience the TURN server description format (with regards to authentication) has to be formatted differently in Chrome and Firefox.
For chrome you can use:{"url": "turn:user#turn.example.com", credential:"password"},
For Firefox the format is:
{"url": "turn:turn.example.com", 'hasCredentials': true, username:"user", credential:"password"},
Maybe you can check the source to see how the turn servers are set in the example.
Edit:
Meanwhilst the format of the servers list has changed in the specification (https://www.w3.org/TR/webrtc/#rtciceserver-dictionary). Currently all implementations i know support the format:
{ "urls": ["turns:turn.example.org", "turn:turn.example.net"],
"username": "user",
"credential": "myPassword",
"credentialType": "password"
}
On Edge however it seems you need to include the query string ?transport=udp in the url.
Related
I am using Ratchet WebSocket in a Windows-based server project that is entirely working in an insecure environment. That is to say that when I navigate my browser to http://www.example.com and connect to the websocket server using ws:// on port 8686 everything works spectacularly.
The server doesn't run through IIS - but instead is executed via php.exe in command prompt like this.
php wsocket-server.php [...parameters...]
However, if run the Ratchet Server and try to connect from https://www.example.com using wss:// the browser simply will not connect to the websocket server, despite the fact that the server starts up fine and the insecure site and connect via ws://
Now, I realize I need to utilize some additional code to include my SSL documentation. This is the relevant code I have in place:
use Ratchet\Server\IoServer;
use Ratchet\Http\HttpServer;
use Ratchet\WebSocket\WsServer;
$websocket_server = new WsServer();
if ($site_secure){
//RUN WSS (SECURE) SERVER
$options = [
'local_cert' => 'c:\inetpub\ssl\2c6fa1928847451c.crt',
'local_pk' => 'c:\inetpub\ssl\2c6fa1928847451c.key',
'allow_self_signed' => true,
'verify_peer' => false
];
$loop = React\EventLoop\Factory::create();
$websocket_server->enableKeepAlive($loop);
$app = new HttpServer($websocket_server);
$insecure_websockets = new \React\Socket\Server('0.0.0.0:'.$port, $loop);
$secure_websockets = new \React\Socket\SecureServer($insecure_websockets , $loop, $options);
$secure_websockets_server = new \Ratchet\Server\IoServer($app, $secure_websockets, $loop);
$secure_websockets_server->run();
}else{
//RUN WS (INSECURE) SERVER
$http_server = new HttpServer($websocket_server);
$server = IoServer::factory($http_server, $port);
$websocket->log ("Initializing ".(($site_secure) ? "Secure " : "Insecure ")."Server ($port)");
$server->run();
}
What I have tried
I have ensured the correct ports are all open in the windows firewall.
I have ensured nothing else is listening on the port using netstat
I have tried using nginx, on a minimal level. I'd prefer to NOT use this method if possible, and was having some initial problems with it starting up so I did not dedicate 100% to it at this time. Ideally, I'd like to use Ratchet's native abilities.
I have searched other similar posts both here and elsewhere, such as this.
I have tried a number of different ports, even the same 8686 as I use in the insecure connection
I am hoping someone can lend me an assist with an issue that has been driving me crazy for 2 weeks. At this point I feel like I'm just trying things to try them and I may be coding myself in circles.
Thank you in advance.
A browser is never going to connect to anything running on port 465. Especially not a WebSocket.
Establishing a WebSocket connection is specified in terms of the Fetch standard. As such, the specific exclusion of this port is found within the latter:
A port is a bad port if it is listed in the first column of the following table.
Port
Typical service
…
…
465
submission
…
…
Now, why are some ports blacklisted? This is a protection against cross-protocol scripting attacks, as once demonstrated (warning: NSFW links) against Firefox and against Safari. Port 465 has been (and still sometimes is) used for SMTP over (pure) TLS, so in this case, an XPS attack might trick a browser into sending mail on the user’s behalf. Blocking those ports is meant to prevent it. Of course, all bets are off when a service runs on a non-standard port.
To make the service available in a browser, all you need to do is change the port number.
When trying to automate one of the webrtc use case via selenium in chrome-headless mode,
I configured following options:
caps := selenium.Capabilities{"browserName": "chrome"}
chromePrefs := make(map[string]interface{})
chromePrefs["profile.default_content_setting_values.media_stream_mic"] = 1
chromePrefs["profile.default_content_setting_values.media_stream_camera"] = 1
chromeCaps := chrome.Capabilities{
Path: "",
Args: []string{
"--ignore-certificate-errors",
"--use-fake-device-for-media-stream",
"--use-fake-ui-for-media-stream",
"--headless",
"--no-sandbox",
"--disable-dev-shm-usage",
},
Prefs: chromePrefs,
}
caps.AddChrome(chromeCaps)
Here I am just using golang selenium wrapper from https://github.com/tebeka/selenium which is over original java driver
So the observation is
in GUI mode(without headless) chrome is generating ice candidate for all the interfaces in my PC and
it connects well with remote peer
In Headless mode, it generates only 1 ICE candidate with type host with mdns example:392f939d-6507-45e1-87da-19b63fb76a9e.local and not anymore and ice connection is failing as remote peer I am using is in not compatible to parse mdns
To overcome I added a STUN server support with peerconnection configured to use example
var peerConnectionConfig = { 'iceServers': [{ 'url': 'stun:192.189.67.565:3478' }], 'bundlePolicy': 'max-bundle'};
And I can clearly see via wireshark, STUN Binding Request is sent and successful mapped Binding Success Response address(192.185.46.57) is sent in return, but its not used by chrome to generate additional ice candidates in this headless mode
I would like to know is there any additional/different configuration essential for chrome-webrtc-ice connections to work when using in headless mode?
Thanks
preference is not supported for headless browser
As of Feb , 2021
https://bugs.chromium.org/p/chromedriver/issues/detail?id=1925
Headless chrome doesn't support preferrences setting . You can use command line arguments only.
the full list of supported arguments are :
https://peter.sh/experiments/chromium-command-line-switches/
Here you can see --blink-settings so ,
try
chrome_options.add_arguments('--use-file-for-fake-audio-capture=random_audio.wav')
chrome_options.add_arguments('--use-file-for-fake-video-capture=random_audio.y4m')
I don't think it works, I have tried it for myself. I believe it is this issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=776649
The application I am testing confirms my suspicion in the logs:
2021-02-31 17:27:19.240 Available media devices:
2021-02-31 17:27:19.241 : audioinput
2021-02-31 17:27:19.241 : videoinput
2021-02-31 17:27:19.241 : audiooutput
2021-02-31 17:27:19.256 Local media is not present NotSupportedError: Not supported
2021-02-31 17:27:19.256 No local media configured
I am trying to reach the list of user devices with a GET here:
https://graph.microsoft.com/beta/me/devices
I am using the Graph Explorer at https://developer.microsoft.com/en-us/graph/graph-explorer
I get a 500 error response.
In addition to the Graph Explorer, I also tried making the HTTP request manually using a token for a demo tenant, for a user that has at least 1 registered device. Same result.
Any ideas what could be wrong here?
In case you have network virtual appliances (NVA) such as firewall to inspect the network traffic, ensure that the required ports are allowed.
Also in case the traffic is force tunneled, ensure that the UDR routes for control plane ip addresses and others are added. Virtual network gateway route propagation settings should also be properly set up. Else, you might have asymmetric routing issues.
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server
http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=759
>> read http://www.informit.com/guides/content.aspx?g=dotnet&s
eqNum=759
connecting to: www.informit.com
** User Error: HTTP forwarding error: Scheme https for URL htt
ps://memberservices.informit.com/checkLogin.ashx?partner=53&r=
http%3a%2f%...
** Near: read http://www.informit.com/guides/content.aspx?g=do
tnet&seqNum=759
>>
This doesn't happen with Firefox, is it possible to "simulate" firefox ?
The URL is being forwarded to an HTTPS page. Rebol/Core and Rebol/View do not support the HTTPS protocol.
An update. REBOL release 2.7.8 includes many goodies. Secure HTTP included. Forward to and from HTTPS. Many other previously premium utilities now included in the proprietary distribution.
As of December 12, 2012, the release date of open source REBOL/3, things have changed.
http://www.rebol.com/article/0519.html
[fanboy]
But even with REBOL/3 open, REBOL 2.7.8 is a very powerful, polished and productive development system. Free to use. Worthy of inclusion in all personal and office toolkits.
[/fanboy]