910669 - Support creating a non-secure TCPSocket

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

See bug 784816 comment 43. In bug 784816, we implement startTLS for a TCPSocket. However, because a socket that can upgrade to secure may consume more resource then a plain socket, we should let user of TCPSocket to create a plain socket (which cannot upgrade to secure) if he don't need startTLS.

Comment 1

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

I'm not sure if this should be proposed to raw socket api, since this is a little bit implementation dependent. And for some API (like ssl in python), upgrading a normal connection to a secure connection can be done by just wrapping the normal socket by ssl, so user don't need to decide if the socket should be able to upgrade when the socket is being created.

I think we could add a boolean 'canUpgradeToSecure' to TCPOption, and set its default value to 'true'. So user can trun off the capability to upgrade by setting 'canUpgradeToSecure' to 'false' to make the TCPSocket consume less memory.

What do you think?

Thanks.

Comment 2

[Honza Bambas (:mayhemer)]

There are two options to implement startTLS:

- as you did, by creating the "starttls" socket type which actually is an ssl socket over tcp ; the ssl socket is left as "pass through" only ; calling startTLS() on it engages the negotiation, actually 'turns the ssl on' of that ssl socket ; but it's already holding all the security objects of psm and nss that is wasting (as you have first pointed out) when the socket is always used only as raw (I presume 99% of cases)

- open only a tcp socket and when startTLS is needed, wrap it by normal "ssl" socket ; this saves resources, allows the upgrade any time (simpler API) ; but, you cannot do that in JS, see [1]

So, to be able to upgrade the socket by wrapping it later by "ssl" socket from JS, we need a new API, probably on nsISocketTransport like addSocketLayer(in string socketType, in unsigned long flags, out nsISupports secInfo).

Comment 3

[Honza Bambas (:mayhemer)]

For the previous comment:

[1] http://mxr.mozilla.org/mozilla-central/source/netwerk/socket/nsISocketProvider.idl#57

Comment 4

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

I see. Thanks, Honza. Then I think I will implement it by wrapping the socket when socket is upgrading to secure.

Comment 5

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

Attachment: WIP: Provide an interface on SocketTransport to add socket layer

Comment 6

[Honza Bambas (:mayhemer)]

Depends also on the TCP socket DOM API.  I though there were 3 options when creating the socket: "tcp", "starttls", "ssl".  If that is still so, then you know the socket will update to ssl when the type is "starttls".  Then you can create the "starttls" type of socket, it's not wasting in that case.

Comment 7

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

(In reply to Honza Bambas (:mayhemer) from comment #6)
> Depends also on the TCP socket DOM API.  I though there were 3 options when
> creating the socket: "tcp", "starttls", "ssl".  If that is still so, then
> you know the socket will update to ssl when the type is "starttls".  Then
> you can create the "starttls" type of socket, it's not wasting in that case.

I'm implementing this like you said in the second option in comment 2. I'd prefer not requiring user to decide whether the socket can upgrade to secure when the socket is created. This should be able to keep the API simpler and we can do it without modifying interface.

Comment 8

[Honza Bambas (:mayhemer)]

(In reply to Patrick Wang [:kk1fff] from comment #7)
> (In reply to Honza Bambas (:mayhemer) from comment #6)
> > Depends also on the TCP socket DOM API.  I though there were 3 options when
> > creating the socket: "tcp", "starttls", "ssl".  If that is still so, then
> > you know the socket will update to ssl when the type is "starttls".  Then
> > you can create the "starttls" type of socket, it's not wasting in that case.
> 
> I'm implementing this like you said in the second option in comment 2. I'd
> prefer not requiring user to decide whether the socket can upgrade to secure
> when the socket is created. This should be able to keep the API simpler and
> we can do it without modifying interface.

Yes, I agree (actually, not that familiar with the spec).  Comment 6 was FYI only.

Comment 9

[BMO Automation]

Firefox OS is not being worked on