need to issue CONNECT before GET while talking to SSL need to pass response to socket so that it can step up.
Dougt, if you have a test case - pls. provide the url here
Status: NEW → ASSIGNED
I don't have a test case. It blocks me from implmenting 31174
Severity: normal → blocker
Marking as feature, nominating for nsbeta2 inclusion as it blocks 31174. The change will be fairly significant in size and will require a few new APIs, so I'm giving the opportunity to high powers to review it.
Summary: need to issue CONNECT before GET while talking to SSL → [FEATURE] need to issue CONNECT before GET while talking to SSL
Target Milestone: --- → M17
Putting on [nsbeta2+] radar for beta2 fix.
Do we have an ETA for this bug?
Yes. End of next week since I'm on J1 this week. May be sooner. It's a feature actually in terms of work invovled (?)
Ok. I implemented my part. The pref is called network.http.proxy.ssl.connect and if set to true it'll do all the connect machinery to the proxy first. Now, we need to implement new APIs with secure socket transport, when it'll first give us a socket transport without ssl, and then we need a new API to turn SSL on on the same transport. Back to dougt.
Assignee: ruslan → dougt
Status: ASSIGNED → NEW
Reassigning all https/cartman/security bugs to valeski. He will be finding new owner(s). This shift is so that I can focus on embedding issues. If the new owner has questions that can not be resovled, I may be able to lend a (quick) hand. over to valeski....
Assignee: dougt → valeski
>Now, we need to implement new APIs with secure socket transport, >when it'll first give us a socket transport without ssl, and >then we need a new API to turn SSL on on the same transport. These APIs are already in place. Create the SocketTransport with the appropriate proxy settings, this will give you a socket with no SSL interference. Then, when you want SSL to activate, get the security info off of the Transport (via GetSecurityInfo), qi to nsIPSMSocketInfo, and call ProxyStepUp() on that.
Assigning to gagan per PDT.
Assignee: valeski → gagan
I'm a bit confused by ruslan's "network.http.proxy.ssl.connect" pref. Is the proper behaviour: 1. when proxying (with either HTTP or HTTPS), we should enable SSL from the beginning (even when talking to the proxy server) 2. but when ruslan's new pref is set, we talk cleartext to the proxy (and use CONNECT) and then enable SSL? And, if correct, is the only place I need to put the SSL "step-up" code the function you marked in nsPipelinedHTTPRequest::RestartRequest? Also, are this bug and 31174 different, or just different parts of the same bug?
Created attachment 11152 [details] [diff] [review] Diff to cause SSL connection to activate after CONNECT proxy is complete
Created attachment 11153 [details] [diff] [review] New version of the previous patch, fixing a stupid mistake of mine
A couple comments on the patch: First, the patch was made from inside mozilla/netwerk/ Second, just to let you know, I've not actually tried it (as I don't have an HTTP proxy to do SSL over). The rest of mozilla still runs fine, but I'm not sure this actually fixes the bug completely. It is, however, how you activate a proxied (thus cleartext) SSL connection from the protocol layer.
ruslan could you review this?
Assignee: gagan → ruslan
*** Bug 31174 has been marked as a duplicate of this bug. ***
ruslan sez that this is a cartman bug now. A fix from cartman would mean a new drop of cartman. (who should this go to now? lord?) gagan adds= not nsbeta2 becuz cartman dependency. So removing + nominating again for a -
Assignee: ruslan → lord
When evaluating, please consider that proxy users are as many as Mac or Unix users.
Putting on [nsbeta2-] radar. Not critical to beta2.
Why does this fix need a new drop of cartman? The proxy code is in the cartman version seamonkey currently uses.
Hmm. Lemme look into it again -> myself
Status: NEW → ASSIGNED
Assignee: lord → ruslan
Status: ASSIGNED → NEW
Cool. Justin's patch seems to do the trick -> checking in
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verif. Windows NT 2000072904
Status: RESOLVED → VERIFIED
RE: justin's ? #1 To my knowledge, nobody has a proxy server that receives an end-to-end SSL connection from the client. This would certainly be desirable, but Proxy Server technology always suffers from a chicken-and-egg problem. If it did, the SSL connection would provide a secure, persistent connection where HTTPS and HTTPS traffic requests could be tunneled by a trusted Proxy. The biggest problem is that you have trust the Proxy w/ the client side certs if you want to do Client Cert Auth to the target content server.
*** Bug 23192 has been marked as a duplicate of this bug. ***
Summary: [FEATURE] need to issue CONNECT before GET while talking to SSL → [FEATURE] "SSL Proxy"/SSL Tunneling (use CONNECT for proxied HTTPS URLS)
You need to log in before you can comment on or make changes to this bug.