[FEATURE] "SSL Proxy"/SSL Tunneling (use CONNECT for proxied HTTPS URLS)

VERIFIED FIXED in M17

Status

()

Core
Networking
P3
blocker
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: dougt, Assigned: ruslan)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-], URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
need to issue CONNECT before GET while talking to SSL
need to pass response to socket so that it can step up.
(Assignee)

Comment 1

18 years ago
Dougt, if you have a test case - pls. provide the url here
Status: NEW → ASSIGNED
(Reporter)

Comment 2

18 years ago
I don't have a test case.  It blocks me from implmenting 31174
Blocks: 31174
Severity: normal → blocker
(Assignee)

Comment 3

18 years ago
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.
Keywords: nsbeta2
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

Comment 4

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]

Comment 5

18 years ago
Do we have an ETA for this bug?
(Assignee)

Comment 6

18 years ago
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 (?)
(Assignee)

Comment 7

18 years ago
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
(Reporter)

Comment 8

18 years ago
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

Comment 9

18 years ago
>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.

Comment 10

18 years ago
Assigning to gagan per PDT.
Assignee: valeski → gagan

Comment 11

18 years ago
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?

Comment 12

18 years ago
Created attachment 11152 [details] [diff] [review]
Diff to cause SSL connection to activate after CONNECT proxy is complete

Comment 13

18 years ago
Created attachment 11153 [details] [diff] [review]
New version of the previous patch, fixing a stupid mistake of mine

Comment 14

18 years ago
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.

Comment 15

18 years ago
ruslan could you review this? 
Assignee: gagan → ruslan
(Assignee)

Comment 16

18 years ago
*** Bug 31174 has been marked as a duplicate of this bug. ***

Comment 17

18 years ago
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
Whiteboard: [nsbeta2+]

Comment 18

18 years ago
When evaluating, please consider that proxy users are as many as Mac or Unix
users.

Comment 19

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]

Comment 20

18 years ago
Why does this fix need a new drop of cartman?
The proxy code is in the cartman version seamonkey currently uses.
(Assignee)

Comment 21

18 years ago
Hmm. Lemme look into it again -> myself
Status: NEW → ASSIGNED
(Assignee)

Comment 22

18 years ago
-> ruslan
Assignee: lord → ruslan
Status: ASSIGNED → NEW
(Assignee)

Comment 23

18 years ago
Cool. Justin's patch seems to do the trick -> checking in
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 24

18 years ago
verif.
Windows NT 2000072904
Status: RESOLVED → VERIFIED

Comment 25

18 years ago
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.

Comment 26

17 years ago
*** Bug 23192 has been marked as a duplicate of this bug. ***

Updated

17 years ago
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.