Skip to content
This repository has been archived by the owner on Sep 20, 2021. It is now read-only.

Long cookie leads to handshake fail #72

Open
hhxsv5 opened this issue Aug 5, 2016 · 8 comments
Open

Long cookie leads to handshake fail #72

hhxsv5 opened this issue Aug 5, 2016 · 8 comments

Comments

@hhxsv5
Copy link

hhxsv5 commented Aug 5, 2016

Hello guys.

When create websocket request with long long cookie, i will get a handshake fail error as the following.
WebSocket connection to 'ws://xxx.com:8088/' failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET

I found out the reason: read 2048 bytes only, cannot get the header "sec-websocket-key".

protected function doHandshake()
    {
        $connection = $this->getConnection();
        $buffer     = $connection->read(2048);
        $request    = $this->getRequest();
        //...
}

Any ideas ?

@Pierozi
Copy link
Member

Pierozi commented Aug 5, 2016

Hi,

Did you confirm your HTTP Request have header greater than 2048 bytes ?
It's true is bit arbitrary to take first 2048 and then split at CR LF

The Hoa\Http Library are not finalized yet and i know we planned to rebuild as PSR-7 recommendation.

@hhxsv5
Copy link
Author

hhxsv5 commented Aug 6, 2016

Hi Pierozi, @Pierozi

Yes, my request header is greater than 2048 bytes because of encrypted cookie string.

I think taking all header is better until get "sec-websocket-key".

We encountered this issue on production environment, and it's really tough to me.

And, we temporarily solved by Cross-Origin: changing Domain into IP, so that the http request won't pass long cookie.

@Hywan
Copy link
Member

Hywan commented Aug 8, 2016

@Pierozi Do you think this is an issue for Hoa\Http instead?

@Hywan Hywan assigned Pierozi and unassigned Hywan Aug 8, 2016
@Pierozi
Copy link
Member

Pierozi commented Aug 8, 2016

@Hywan I guess yes, because we consider the responsibility of extract http header from Hoa\Http.
Maybe we should reconsider the implementation with a method can accept stream for extract itself the header instead spread first 2048 bytes.

In short time, maybe we can do a quick patch by moving 2048 as class parameter.
Like this he can change the value by 4096 ore more and be sure the header is complete.

@Hywan
Copy link
Member

Hywan commented Aug 9, 2016

@Pierozi Agree. Could you write the PRs and open the respective issues?

@Pierozi
Copy link
Member

Pierozi commented Aug 15, 2016

Hello @hhxsv5 can you tell us what's the size of your header or provide us an example.
Thanks.

@undsoft
Copy link

undsoft commented Oct 11, 2017

Same issue happens for me.
My header:

GET /?token=tokentokentokentokendaipps0QKwHF__1507723994 HTTP/1.1
Host: host.hosthost.com:port
Pragma: no-cache
Cache-Control: no-cache
Origin: https://origin.originorigi.co
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: nb-NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en-US;q=0.2,en;q=0.2
Cookie: _csrf=5a1de5518e830f911089483d8ba8d724085da4527db73744d61102c1e47742eca%3A2%3A%7Bi%3A0%3Bs%3A5%3A%22_csrf%22%3Bi%3A1%3Bs%3A32%3A%222iFzRjpGxNX8uD7EgO82Op6HroGPQcZw%22%3B%7D; ids_for_initial_open930={"locations":["2147"],"sets":["873"]}; ids_for_initial_open1031={"locations":["2423"],"sets":["971"]}; ids_for_initial_open1026={"locations":["2417"],"sets":["966"]}; ids_for_initial_open1025={"locations":["2415"],"sets":["965"]}; ids_for_initial_open1036={"locations":["2451"],"sets":["976"]}; ids_for_initial_open1051={"locations":["2476"],"sets":["990"]}; ids_for_initial_open1042={"locations":["2461"],"sets":["981"]}; ids_for_initial_open1030={"locations":["2422"],"sets":["970"]}; ids_for_initial_open1029={"locations":["2420"],"sets":["969"]}; ids_for_initial_open1086={"locations":["2584","2585"],"sets":["1020"]}; ids_for_initial_open468={"locations":["1189"],"sets":["448"]}; ids_for_initial_open1024={"locations":["2413"],"sets":["964"]}; _ga=GA1.2.396346604.1504076802; _gid=GA1.2.289453770.1507618974; _gat=1; menu-state=collapsed; PHPSESSID=7p0c1i26b3dop2tcq1fjqn4fm1; authToken=1k-0QK4lir8Hl0_rIS53daipps0QKwHF__1507723994; _identity=8a87ba293fe1fff808a42c816cc63f29fac3419800739442443c2b3f4596a994a%3A2%3A%7Bi%3A0%3Bs%3A9%3A%22_identity%22%3Bi%3A1%3Bs%3A19%3A%22%5B2433%2Cnull%2C2592000%5D%22%3B%7D
Sec-WebSocket-Key: gdwp6V7NlollUDIVciEO6w==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
X-Forwarded-For: 11.111.111.93
X-Forwarded-Host: host.hosthoste.co:8443
X-Forwarded-Server: ip-111-11-11-7.eu-west-1.compute.internal
Upgrade: WebSocket
Connec

@undsoft
Copy link

undsoft commented Oct 11, 2017

I can work around this by setting up an apache websocket proxy.
This proxy fixes my problems with SSL that I had with the library and also strips cookies.

Example config:

Listen 8443
<VirtualHost *:8443>

  SSLEngine             on
  SSLCertificateFile    "/etc/pki/tls/certs/server.crt"
  SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"

  SSLProxyEngine On
  ProxyPreserveHost On
  ProxyRequests Off
  RequestHeader unset Cookie

  ProxyPass /wss ws://127.0.0.1:8080/
  ProxyPassReverse /wss ws://127.0.0.1:8080/

</VirtualHost>

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

4 participants