Secure TCP socket commincation from a Chrome Application does not work after Authentication
Reported by
t...@gohealthcast.com,
Mar 15 2017
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Steps to reproduce the problem:
1. Login to an HTTPS site using “chrome.sockets.tcp”. Authentication using TLS. Example..
chrome.sockets.tcp.create({}, () => {
chrome.sockets.tcp.setPaused(this._socketId, true, () => {
chrome.sockets.tcp.connect(that._socketId, that._host, that._port /* 443 */, () => {
chrome.sockets.tcp.secure(this._socketId, (secureResult) => {
chrome.sockets.tcp.setPaused(that._socketId, false, () => {
console.log("connection complete with TLS handshake");
});
});
});
});
});
2. Send post
var arr = this._str2ab(httpPost + '\n');
chrome.sockets.tcp.send(this._socketId, arr, () => {
});
3. Receive response
_onReceiveCallback(receiveInfo) {
if (receiveInfo.socketId != this._socketId)
return;
if (this._callbacks.recv) {
var str = this._ab2str(receiveInfo.data);
if (this._parser.addData(str)) {
// GET AUTHENTICATION COOKIE TO BE USED
// WITH OTHER REQUESTS.
// Access the response header Set-Cookie header
// Get authentication cookie value to include in request
// headers
}
}
}
4. Socket is disconnected
5. Sometime later, start a new HTTPS request to the same server ---- go to step 1. We have already been authenticated and we include the cookie in the request header. The request will FAIL in the connection handler. It is a new request, and we are unable to get out of the connection part of the socket.
What is the expected behavior?
We should be able to send out a subsequent HTTPS POST to the same server after authentication. A failure occurs in the connection logic the second attempt to send a request
What went wrong?
The second connection seems to be all messed up with handshaking. We are assuming it might have something to do with cookies. This is a Chrome Application, so there is not document cookie support. See https://developer.chrome.com/apps/app_deprecated
Did this work before? No
Does this work in other browsers? Yes
Chrome version: 56.0.2924.87 Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 25.0 r0
The TLS handshaking correctly works for the initial login/authentication. However, the second request to that server will fail
,
Mar 15 2017
Adding HTTP2 on the off chance that this could have to do with a conflict between the internal browser behavior (which is to multiplex multiple connections to the same server over a single socket) and the app (which is using the socket interface directly and may be disconnecting the socket). But I'm not at all sure how the chrome.sockets interface interacts with the internals of the network stack code.
,
Mar 16 2017
,
Mar 28 2017
Do you have any information about the type of failure (e.g. error codes, exceptions, timeout etc)? Have you looked at a tcpdump to investigate further (e.g. is the connection closed or reused)? Have you looked at a net-internals dump to see if there is any helpful information? http://dev.chromium.org/for-testers/providing-network-details Why are you using chrome.sockets.tcp instead of XMLHttpRequest?
,
Mar 28 2017
,
Apr 3 2017
,
Apr 20 2017
tlee@gohealthcast.com: If you don't provide the data requested in comment #4, we can't make forward progress here, and will have to just close the issue.
,
Apr 27 2017
Pinging tlee@, please provide the info requested in comment #4.
,
May 29 2017
No feedback was received in the last 30 days from reporter "tlee@gohealthcast.com", so archiving this. Please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ligim...@chromium.org
, Mar 15 2017