Indy 10.6.2, trying to 'GET' https://dapi.binance.com/dapi/v1/time
The handshake fails with 'Alert protocol version'
That's weird, because the server should support TLSv1.2, and according to Wireshark, my program does everything in TLSv1.2
I tried doing the same query with my browser (successfully). The 'Server hello' packet contained a Cypher that my program offers (so I think the problem is not my CipherList)
CLIENT HELLO
ALERT: HANDSHAKE FAILURE
ALERT: PROTOCOL VERSION
At this point I don't quite understand what is the actual problem. Why does the handshake fail, why doesn't server like my 'protocol version' while uses it itself? o_O
Related
How to log (in access_log) the number of bytes sent to the client during a SSL/TLS Handshake in nginx?
Any third party open source/paid nginx module will also work.
I looked into the docs but didn't find anything.
I'm using ESP-01/ESP8266 Wifi module to make SSL connection to my google firebase project.
I'm already able to write/read to/from the database using HTTP protocol and REST API, and my next goal is to switch the protocol to WebSocket, in order the server and client (my board) can speak this protocol after the initial handshake. Currently I'm not even making the handshking to work, and this is the point I'm currently stuck.
What I tried so far:
(1) First, I open TCP socket with SSL, connect to wss://eletronica-ab6b1.firebaseio.com, port 443. The SSL steps are being done by the wifi module, SSL/TLS is one of its features.
(2) After connection is up, I send the following HTTP packet to the server, actually is only a HTTP header, without data. Packet:
GET /January HTTP/1.1
Host: eletronica-ab6b1.firebaseio.com
Upgrade: Websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
This is the response of the server:
Why I used "January"? Check, this is my database:
What do I need to change in order to work? I mean in terms of content of the headers and also the connection to the domain.
Regards.
EDIT:
My final goal is: the board stablish a constant TCP connection to firebase server. When a value of the database be changed, the board will be notified by the server through the protocol, so there will be no need of the board to stay polling the server (each X seconds) to know if the value was changed. Am I on the right way to reach this? Using WebSocket protocol?
I've never tried it but you could find a way to achieve something similar to websockets using gRpc https://firebase.google.com/docs/firestore/reference/rpc/
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.
https://en.m.wikipedia.org/wiki/HTTP/1.1_Upgrade_header
Given the following:
Connect on port 80
Request Upgrade: TLS/1.x
Request Upgrade: h2c or Upgrade: websocket
Will the resulting connection/protocol still be using TLS or will it be replaced by an unsecure one?
Note: I'm not primarily looking for the current status of popular clients/servers, but rather any hints in the specification(s) which may lead to a more desirable implementation.
I'm not sure if your request makes sense and, even if it did, if any implementation would support it - or if you could rely on what support that might be.
Connect on port 80
Request Upgrade: TLS/1.x
Ok this bits fine. It would basically ask to speak TLS over port 80 and over http and is defined by RFC-2817. It's highly unusual as standard would be to speak TLS only over https scheme and on port 443 (or a non-standard port like 8443), but in theory this would work. Note also the Connection header must also be set to Upgrade.
Connect on port 80
Request Upgrade: TLS/1.x
Request Upgrade: h2c
This is where it starts to get tricky. The h2c protocol is an unsecured HTTP/2 connection (i.e. without TLS) but, combined with your first header, you are asking this to be over TLS (multiple headers are permitted over HTTP btw). I guess, in theory, this could work, similar to how it would work under HTTP/1.1 above, except that the HTTP/2 spec clearly states:
the "h2c" protocol identifier describes a protocol that does not use TLS.
and
implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLS-ALPN].
I would therefore consider above connection a violation of spec and not confirm that upgrade.
Connect on port 80
Request Upgrade: TLS/1.x
Request Upgrade: websocket
The websocket spec is less clear on this. It does state:
By default, the WebSocket Protocol uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled over Transport Layer Security (TLS) [RFC2818].
and also:
A |wss| URI identifies a WebSocket server and resource name and indicates that traffic over that connection is to be protected via TLS (including standard benefits of TLS such as data confidentiality and integrity and endpoint authentication).
However there is nothing that I can see that forbids a TLS connection over the |ws| URI, or even using the |wss| URI over port 80. However I would imagine that, since this is not explicitly defined, there would be no guarantees as to whether this would work, or if the connection would be secure or not.
I am working on linux.
I have a HTTP client which requests some data from the HTTP server. The HTTP client is written in C and HTTP server is written in perl.
I want to simulate TCP re-transmission timeouts at the client end.
I assume that closing the socket gracefully would not result in client to re-transmit the requests.
So I tried the following scenario:
Exit the Server as soon as it gets the HTTP GET request. However, I noticed that once the application exits, the socket is still closed gracefully. I see that the server initiates FIN.ACK messages towards the client even though the application has not called "close" on the socket. I have noticed this behaviour on a simple TCP server and client written in C program as well.
Server does not send any response to the client's GET request. In this case I notice that there is still FIN, ACK sent by the server.
Seems that in these cases the OS (linux) takes care of closing the socket with the peer.
Is there any way to suppress this behaviour (using ioctl or setsockopt options) or any other way to simulate the TCP re-transmission timeouts.
You could try setting firewall rules that block the packets going from the server to the client, which would cause the client to re-transmit the quests. On Linux, this would probably be done using iptables, but different distributions have different methods of controlling it.
This issue was previously discussed here