Running Apache v2.4, PHP v5.6 w/ php-fpm, on CentOS 7
So I'm trying to get wss working with stunnel & Ratchet. I've got Ratchet's Hello World (http://socketo.me/docs/hello-world) working successfully with the test code on non-ssl at port 8080. I can telnet from the same machine, as well as telnet from a a different machine.
Through reading, I know that ratchet doesn't support ssl connections, but does by wrapping the communications with stunnel, so I setup stunnel with an appropriate cert listening on port 8443, which appears to be working (as evidenced by the log file).
When I try to make a connection using wss from Firefox's scratchpad, I get the following error: Firefox can't establish a connection to the server at wss://testserver.testdomain.com:8443 I can see the connection being created through the various log files, however somewhere along the line communications is failing since I can't create a solid wss connection. Any ideas on what I'm missing or where I'm screwing up? Log/code below
Scratchpad Code
var conn = new WebSocket('wss://testserver.testdomain.com:8443');
conn.onopen = function(e) {
console.log("Connection established!");
};
conn.onmessage = function(e) {
console.log(e.data);
};
Stunnel config:
cert = /etc/httpd/ssl/ov_wildcard.pem
[hublistener]
accept = 8443
connect = 8080
Stunnel log:
2016.05.11 14:43:28 LOG5[38759:140614807435328]: stunnel 4.56 on x86_64-redhat-linux-gnu platform
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Reading configuration from file /etc/stunnel/stunnel.conf
2016.05.11 14:43:28 LOG5[38759:140614807435328]: FIPS mode is enabled
2016.05.11 14:43:28 LOG4[38759:140614807435328]: Insecure file permissions on /etc/httpd/ssl/cert.pem
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Configuration successful
2016.05.11 14:45:59 LOG5[38765:140614807430912]: Service [hublistener] accepted connection from ***.***.***.***:39124
2016.05.11 14:45:59 LOG5[38765:140614807430912]: connect_blocking: connected 127.0.0.1:8080
2016.05.11 14:45:59 LOG5[38765:140614807430912]: Service [hublistener] connected remote server from 127.0.0.1:59795
Ratchet sample output:
[zxurian#ariel dev-hub]$ php module/HubListener/websocket.php
New Connection! (307)
New Connection! (317)
Connection 317 sending message "second window line 1
" to 1 other connection
Connection 317 sending message "second window line 2
" to 1 other connection
New Connection! (318)
Connection 318 sending message "GET / HTTP/1.1
Host: testserver.testdomain.com:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: https://testserver.testdomain.com
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: PrWlBjR2q6a0syT4oplnAQ==
Cookie: PHPSESSID=ci7102qouvqprhdpk483hv6ar3; exclusive_offers_popup=1; __utma=213556497.27501638.1462814210.1462827970.1462831402.3; __utmc=213556497; __utmz=213556497.1462814210.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmv=213556497.|1=l=%2F=1
x-insight: activate
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
" to 2 other connections
Telnet Connection 1
[zxurian#ariel ~]$ telnet 127.0.0.1 8080
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
second window line 1
second window line 2
GET / HTTP/1.1
Host: testserver.testdomain.com:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: https://testserver.testdomain.com
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: PrWlBjR2q6a0syT4oplnAQ==
Cookie: PHPSESSID=ci7102qouvqprhdpk483hv6ar3; exclusive_offers_popup=1; __utma=213556497.27501638.1462814210.1462827970.1462831402.3; __utmc=213556497; __utmz=213556497.1462814210.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmv=213556497.|1=l=%2F=1
x-insight: activate
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
I have a Ratchet WebSocket running on my own machine and am also using Apache2.4
To make it work over SSL I did:
Proxy pass the socket
inside (/etc/apache2/)apache2.conf I added
//added for the websocket over SSL
ProxyPass /wss/ ws://alpha.example.com:8080/
this passes my websocket running on port 8080 to wss://alpha.example.com/wss/
to make sure your stunnel config is correct, this is what I did
inside of (/etc/stunnel/)stunnel.conf
cert = /etc/letsencrypt/live/www.example.com/cert.pem
key = /etc/letsencrypt/live/www.example.com/privkey.pem
[wss]
accept = 8082
connect = 8080
REMINDER: change the paths to the keys I used to thee paths your keys are using.
inside the PHP file that starts my server I user port 8080 as in the ratchet example
$webSock->listen(8080, '0.0.0.0'); // Binding to 0.0.0.0 means remotes can connect
Related
I'm using
- redoscks/0.5 (libevnt-2..8)
- on a 2018-4 4.18.0kliad64.
I need to connect to an http-proxy that require authentication and I want to use redsocks to redirect to that proxy (by means of iptables) some hhtp/https traffic.
I set redsocks.conf in this way
base {
log_debug = on;
log_info = on;
log = "stderr";
daemon = off;
redirector = iptables;
}
redsocks {
local_ip = 127.0.0.1;
local_port = 12345;
ip = 10.12.yyy.xxx;
port = 8080;
// known types: socks4, socks5, http-connect, http-relay
type = http-connect;
login = "myUser";
password = "myPass";
disclose_src = false;
}
But it seems that redsocks does NOT consider my credential.
I sniff traffic with wireshark and compare it with a proxychains connection that works fine (with same IP,Port,user and pass parameter).
wireshark session with redsocks:
[from redsocks to proxy]
CONNECT 216.58.205.100:80 HTTP/1.0
[from proxy to redsocks]
HTTP/1.0 407 authenticationrequired
Via: 1.0 10.12.yyy.xxx (McAfee Web Gateway 7.7.2.7.0.24770)
Date: Mon, 11 Feb 2019 09:25:22 GMT
Content-Type: text/html
Cache-Control: no-cache
Content-Length: 4040
Proxy-Connection: Close
Proxy-Authenticate: Negotiate
Proxy-Authenticate: Basic realm="McAfee Web Gateway"
....
wireshark session with proxychains:
[from redsocks to proxy]
***** CONNECT 185.63.145.1:443 HTTP/1.0
Proxy-Authorization: Basic ZjI1MjE5Y...*****
[from proxy to redsocks]
HTTP/1.0 200 Connection established
...
So it seems that proxychains (which work fine) send a CONNECT command together with a Proxy-Authorization, but redsocks no and because of that proxy close the connection.
What's wrong on my config setup ?
Thanks.
As discussed in my other question there is no support for websockets authentication in Knox, but as a temporary solution we could handle authentication in our backend service. Our test has shown however that Knox does not pass Authorization header to the backend.
[client]$ curl -i -u '<user>:<password>' https://knox-server/gateway/default/myservice/ping
# 8090 is our backend port
[knox-server]$ ngrep -W byline port 8090
interface: eth0
filter: ( port 8090 ) and ((ip || ip6) || (vlan && (ip || ip6)))
#
T <knox-server>:59118 -> <myservice>:8090 [AP]
GET /ping?doAs=<user> HTTP/1.1.
X-Forwarded-For: <client>.
X-Forwarded-Proto: https.
X-Forwarded-Port: 443.
X-Forwarded-Host: <knox-server>.
X-Forwarded-Server: <knox-server>.
X-Forwarded-Context: /gateway/default.
User-Agent: curl/7.54.0.
Accept: */*.
Host: <myservice>:8090.
Connection: Keep-Alive.
Accept-Encoding: gzip,deflate.
.
#
T <myservice>:8090 -> <knox-server>:59118 [AP]
HTTP/1.1 200 OK.
Date: Sat, 14 Oct 2017 14:27:58 GMT.
X-Application-Context: myservice:prod:8090.
Content-Type: text/plain;charset=utf-8.
Content-Length: 4.
.
PONG
How should I configure Knox (0.12.0 from HDP 2.6.2) to make it pass Authorization header to the backend for websocket connection?
While writing this question I realised that there is a ticket KNOX-895 resolving the issue of passing cookies and headers to a backend service in Knox 0.14.0.
[EDIT]
I cloned knox git repo (commit 92b1505a), which includes KNOX-895 (2d236e78), run it locally with added websocket service to sandbox topology.
[tulinski]$ wscat -n --auth 'user:password' -c wss://localhost:8443/gateway/sandbox/echows
[tulinski]$ sudo ngrep -W byline host echo.websocket.org
#
T 192.168.0.16:59952 -> 174.129.224.73:80 [AP]
GET / HTTP/1.1.
Host: echo.websocket.org.
Upgrade: websocket.
Connection: Upgrade.
Sec-WebSocket-Key: Z4Qa9Dxwr6Qvq2QAicsT5Q==.
Sec-WebSocket-Version: 13.
Pragma: no-cache.
Cache-Control: no-cache.
Authorization: Basic dXNlcjpwYXNzd29yZA==.
.
##
T 174.129.224.73:80 -> 192.168.0.16:59952 [AP]
HTTP/1.1 101 Web Socket Protocol Handshake.
Connection: Upgrade.
Date: Mon, 16 Oct 2017 14:23:49 GMT.
Sec-WebSocket-Accept: meply+6cIyjbH+Vk2OsAqKJDWic=.
Server: Kaazing Gateway.
Upgrade: websocket.
.
Authorization header is passed to the backend service.
I need to configure Burp Suite to intercept data between web browser and proxy server. The proxy server requires a basic authentication (Username & Password) while connecting for the first time in each session. I have tried the 'Redirect to host' option in Burp Suite(Entered the proxy server address and port in the fields):
Proxy >> Options >> Proxy Listeners >> Request Handling
But I can't see an option to use the authentication that is required while connecting to this proxy server.
While accessing google.com, the request headers are:
GET / HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (X11; Linux i686) KHTML/4.13.3 (like Gecko) Konqueror/4.13
Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8
Accept-Encoding: gzip, deflate, x-gzip, x-deflate
Accept-Charset: utf-8,*;q=0.5
Accept-Language: en-US,en;q=0.9
Connection: close
And the response is:
HTTP/1.1 400 Bad Request
Server: squid/3.3.8
Mime-Version: 1.0
Date: Thu, 10 Mar 2016 15:14:12 GMT
Content-Type: text/html
Content-Length: 3163
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from proxy.abc.in
X-Cache-Lookup: NONE from proxy.abc.in:3343
Via: 1.1 proxy.abc.in (squid/3.3.8)
Connection: close
you were on the right track, just at the wrong place. You need to setup an upstream proxy at:
Options>>Connections>>Upstream proxy
There you can also setup the authentication
Options>>Connections>>Platform authentication
Here you can create different auth configurations, which will be done if the server requests it.
What is a common approach in authenticating of user session for websocket connection?
As I understand websocket message contains data only with no headers. Thus authorization cookie is not available to server backend. How should application distinguish messages from different clients?
Which websocket server are you using?
if your webserver and websocketserver are the same, you could send the sessionid via websocket and force-disconnect any client that does not send a valid sessionid in his first message.
if your websocketserver parses the HTTP headers sent in the HTTP upgrade request properly, it may also save any cookie. this is what a request of my firefox (version 35) looks like:
GET /whiteboard HTTP/1.1
Host: *:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: *
Sec-WebSocket-Protocol: whiteboard
Sec-WebSocket-Key: iGPS0jjbNiGAYrIyC/YCzw==
Cookie: PHPSESSID=9fli75enklqmv1a30hbdmg1461
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
as you see, the phpsessionid is transmitted fine. check the documentation of your websocketserver if it parses the HTTP headers. remember that cookies will not be sent if the websocket's domain differs from the webserver's domain.
I'm currently trying to connect to a webservice placed on https://xxx.xxx.xx/myapp
It has anonymous access and SSL enabled for testing purposes atm.
While trying to connect from the 3G network, i get Status 403: Access denied. You do not have permission to view this directory or page using the credentials that you supplied.
I get these headers while trying to connect to the webservice locally:
Headers
Request URL:https://xxx.xxx.xx/myapp
Request Method:GET
Status Code:200 OK
Request Headers
GET /myapp/ HTTP/1.1
Host: xxx.xxx.xxx
Connection: keep-alive
Authorization: Basic amViZTAyOlE3ZSVNNHNB
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response Headers
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 16 Feb 2012 12:26:13 GMT
Content-Length: 622
But when accessing outside the local area, we get the big ol 403. Which in turn wants credentials to grant the user access to the webservice.
However, i've tried using the ASIHTTPRequest library without success, and that project has been abandoned. And they suggest going back to NSURLConnection.
And i have no clue where to start, not even which direction to take.
-connection:(connection *)connection didRecieveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
The above delegate method of NSURLConnection doesnt even trigger. So i have no idea what so ever how to authenticate myself.
All i get is the parsed results of the xml elements of the 403-page.
I needs dem seriouz helps! plx.
This was all just a major f-up.
The site had ssl required and enabled, and setting ssl required for the virtual directories does some kind of superduper meta-blocking.
So, by disabling ssl required for the virtual directories, it runs over ssl and is not blocking 3G access..