We've installed a Mattermost server and it works well.
We can only connect via http. Https gives an error.
The line of code that fails is
webSocketClient, err := model.NewWebSocketClient4("ws://mattermost.example.com", client.AuthToken)
make run
go run *.go
Mattermost Bot Sample
Server detected and is running version 5.1.0
We failed to connect to the web socket
Error Details:
model.websocket_client.connect_fail.app_error
model.websocket_client.connect_fail.app_error
websocket: bad handshake
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x58 pc=0x13e1e55]
We opened up the http port 8065 and when we connect to port 8065, without ssl, it works.
webSocketClient, err := model.NewWebSocketClient4("ws://mattermost.example.com:8065", client.AuthToken)
What is the protocol for a secure websocket?
Normal websocket uses "ws://example.com"
Secure websocket uses "wss://example.com"
Note that some frameworks automatically handle this for you if you just leave off the ws: or wss: entirely.
Related
When sending Post to a https rest api endpoint in my local network I'm receiving the error:
wsarecv: An existing connection was forcibly closed by the remote host.
However, when I use Postman on the same server it works fine.
The problem is specific to my Go http configuration, I'm just not sure what the problem is.
I've tried disabling TLS on the http client but the problem persists:
// disable SSLVerify
func getHttpClient() *http.Client {
tr := &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}} // disable SSL integrity check
return &http.Client{Transport: tr}
}
edit: correction, it's being routed over a proxy, probably Bluecoat, that's performing some MitM operations. But still can't figure out why it works over Postman, but not with Golang.
I have a service which will listen on port 8443 after it is launched.
I have xinetd configured to start my service when a connection is made on port 8443.
So Xinetd should launch my application and then let my application handle any more incoming connections.
I'm getting repeated "warning: can't get client address: Transport endpoint is not connected" and then Xinetd disables my service for 10 seconds.
This only happens when I set wait = yes.
Stopping my application from listening to port 8443 doesn't make a difference.
Is my understanding of xinetd wait flag correct or am I doing something wrong with the xinetd configuration?
I've looked at man pages, wait=yes is usually associated with UDP but nothing in there says you can't use it with TCP.
I searched on SO and everything I found has tcp working with wait=no.
I am getting the following errors when connection to xinetd.
5786]: warning: can't get client address: Transport endpoint is not connected
5564]: EXIT: MyApplication status=1 pid=5786 duration=0(sec)
5564]: START: MyApplication pid=5787 from=<no address>
5787]: warning: can't get client address: Transport endpoint is not connected
5564]: EXIT: MyApplication status=1 pid=5787 duration=0(sec)
5564]: Deactivating service MyApplication due to excessive incoming connections. Restarting in 10 seconds.
5564]: FAIL: MyApplication connections per second from=<no address>
5564]: Activating service MyApplication
My configuration is:
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = user
server = /usr/bin/MyApplication
port = 8443
type = UNLISTED
flags = IPv4
Just incase anyone else comes across this, I was looking for the same thing. From this comment by one of the maintainers Steve Grubb here, he says
A wait service is one that accepts the
connection. telnet does not accept the connection - it expects the connection to
be accepted and the socket dup'ed to the stdin/out descriptors.
There is also no way for xinetd to check to see if a child has accepted the
connection. Therefore, when you have a program that's configured as a wait
service and it doesn't accept the connection, the socket is still readable when
xinetd goes back to the select loop. Around and around it goes.
The child server is launched from when xinetd forks then calls exec_server. When wait=true, as mentioend above the child process must accept the connection on the socket. To get the socket the file descriptor with value 0 can be used with accept. I am using python with the following,
import socket
s = socket.fromfd(0, socket.AF_INET, socket.SOCK_STREAM)
print(s.accept())
which returns (conn, address) where conn is a new socket object usable to send and receive data on the connection.
From the man pages
wait This attribute determines if the service is single-threaded or multi-threaded and whether or not xinetd accepts the connection or the server program accepts the
connection. If its value is yes, the service is single-threaded; this means that xinetd will start the server and then it will stop handling requests for the
service until the server dies and that the server software will accept the connection. If the attribute value is no, the service is multi-threaded and xinetd
will keep handling new service requests and xinetd will accept the connection. It should be noted that udp/dgram services normally expect the value to be yes
since udp is not connection oriented, while tcp/stream servers normally expect the value to be no.
So if you have wait=yes you are single threaded. Once there is a connection nothing else is is able to connect till your current sessions disconnects or the script ends.
I'm trying to connect to a proxy server to start an HTTP CONNECT tunnel. The proxy server uses authentication. This code however fails to work:
conn, err := net.Dial("tcp", "[user:pass#111.222.333.444]:5555")
Even though the host exists, I get an error:
"dial tcp: lookup user:pass#111.222.333.444: no such host"
The string format I'm using was described in this post. Can't seem to get it to work though.
https://stackoverflow.com/a/8858209/6767074
I eventually found the problem. The net.Dial() method wasn't the one concerned with proxy authentication.
I just had to fill in the "Proxy-Authorization" header of the request before calling for am HTTP response. So my TCP address became:
conn, err := net.Dial("tcp", "111.222.333.444:5555")
I m trying to implement the following scenario in WinRT in c++ ,
Client----TLS -------proxy------TLS------->RemoteTLSserver
So,I did make a TCP connection with proxy,Then send a HTTP connect request for Remote TLS server. And I am successful to do it:
Client------TCP---------->proxy---------TCP(forwarding)------>Remote TLS server.
Then I use UpgradeToSslAsync(SocketProtectionLevel::Tls10,validationHostName)
(here I use my TLS server HostName as validation host).
I am getting an Exception: The token supplied to the function is invalid
Note: UpgradeToSslAsync() works with my TLS server if there is no proxy in between.
Is it possible in Windows RT to relay data through proxy server in TLS protocol?
today i used bitvise tunnelier for tunneling and i set the listening proxy in mozilla. but unlucky tunnelier didn't rcognize the proxy protocol. here the output.
19:45:17.893 Initializing SOCKS / HTTP CONNECT proxy on 127.0.0.1:1080 succeeded.
19:46:02.266 (unrecognized proxy protocol) connection from 127.0.0.1:60300 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:03.991 (unrecognized proxy protocol) connection from 127.0.0.1:60301 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:05.803 (unrecognized proxy protocol) connection from 127.0.0.1:60302 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:27.439 (unrecognized proxy protocol) connection from 127.0.0.1:60303 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:28.280 (unrecognized proxy protocol) connection from 127.0.0.1:60304 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:50.534 (unrecognized proxy protocol) connection from 127.0.0.1:60305 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:50.578 (unrecognized proxy protocol) connection from 127.0.0.1:60306 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:47:21.361 (unrecognized proxy protocol) connection from 127.0.0.1:60307 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
I didn't know whats wrong with this. So i decided to install Proxifier aaaand BINGO!! it worked!!. here the output after using proxifier:
19:51:26.433 Accepted HTTP CONNECT connection from 127.0.0.1:60598 to 173.194.38.140:80.
19:51:26.434 Accepted HTTP CONNECT connection from 127.0.0.1:60601 to 173.194.38.140:80.
19:51:26.434 Accepted HTTP CONNECT connection from 127.0.0.1:60604 to 173.194.38.139:80.
19:51:26.434 Accepted HTTP CONNECT connection from 127.0.0.1:60607 to 173.194.38.139:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60610 to 173.194.38.139:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60613 to 173.194.38.140:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60616 to 173.194.38.140:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60619 to 173.194.38.140:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60622 to 173.194.38.140:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60625 to 173.194.38.140:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60628 to 173.194.38.140:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60631 to 74.125.235.15:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60634 to 74.125.235.15:80.
19:51:48.413 Closing HTTP CONNECT connection from 127.0.0.1:60328, sent: 1060, received: 3609.
And in the other case, few days ago i used privoxy with Mozilla. but unfortunately the ip i used blocking facebook page. So i decided to use proxifier again to chain with privoxy.. aaaand bingo again.. it worked!!!
So guys, do you know what is really happened in Proxifier?. for some reason i need to use this feature in my Ubuntu desktop :) . please tell me if you know something about this :)
Ok guys thanks for helping me, but i have found the answer bymyself :p.. okay, it's called proxy chaining, the proxyfier make 2 output from one input (imho). first output is dirctly to proxy that we set to proxifier and the second output is from dns that set in the proxifier. so those two make diffrent way of the output.
firefox >> proxifier >>> 1. to dns server >> internet
2. to proxyserver we set >> internet
here example of my case:
i use privoxy to add header host on http connection, but unfortunately it would make bad request because there are 2 hosts in one request.
firefox >> privoxy(with two hosts header) === bad request
so you need something to resolve the problem. yes right it is a proxychaining app with dns support.
firefox >> proxifier >> privoxy(with two hosts header) === good request :)
So you need something app with dns support for chaining with dns server to resolve the bad request..
if you found my opinion is wrong please correct me, because it is just my humble opinion :)