Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/websocket: client auth for outgoing connections #1913

Closed
gopherbot opened this issue Jun 3, 2011 · 15 comments
Closed

x/net/websocket: client auth for outgoing connections #1913

gopherbot opened this issue Jun 3, 2011 · 15 comments
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 3, 2011

by nroos@webware-experts.de:

In outgoing websocket connections, the client cannot be authenticated. In
websocket.Dial(), tls.Dial() is called with a nil/empty tls.Config. This tls.Config
should contain the client's certificates needed for authentication.

Suggestions:

- Add a tls.Config parameter to websocket.Dial()

- Add a function websocket.DialTLS()

- Add a function tls.SetDefaultConfig(), where the config could be filled with the
client certificates and is used when tls.Dial() is called without a config
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Jun 12, 2011

Comment 1 by jdnurmi@qwe.cc:

I've attached a patch I'm using currently;  It adds a *tls.Config to websocket.Dial;  It
may be nil for both ws and wss sockets (and will use the default configuration in the
latter if so).
I think this 'optional' parameter is the simplest way to add this functionality, though
I think being able to modify the 'default' tls.Config has merits as well.

Attachments:

  1. ws.patch (1203 bytes)
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jun 13, 2011

Comment 2:

This would bring it up to 2 optional positional parameters, of 4.  And not next to each
other.  Kinda gross, imo.
I have a small vote towards making a new DialTLS, but I'll defer to the other Gophers. 
I'm not sure who owns websocket.
@rsc
Copy link
Contributor

@rsc rsc commented Jun 13, 2011

Comment 3:

ukai@google.com does
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Jun 13, 2011

Comment 4 by ryanbressler:

I also ran into this issue. What I would really like is an exported function that
accepts a *Conn which could be from tls.Dial, net.Dial or wherever. You could almost
just export websocket.newClient but you would have to also export websocket.handshake.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Jun 14, 2011

Comment 5 by jdnurmi@qwe.cc:

I'm uninclined to have a strong opinion on how it _should_ be done, but as it is, .Dial
performs 'magic' based on the Scheme of the passed in URL;  The fact that this then
implies an unmodifiable tls.Config seems to be worse than having 2 optional parameters
-- especially if (for whatever reason) I don't trust the /etc/ssl/certs/... bundle for
my application.
So that is to say: If .Dial will magically upswing to TLS based on a potentially
user-specified parameter, I want to be able to control TLS parameters in one call;
  
- If Dial were re-formed to something like (host,port,resource,ws_origin,ws_protocols)
and a TLS version, then I'd be unconcerned by the magic, but by the length of the call.  
-  I also don't like the idea of having to be 'smart' if i'm accepting a user WS://URL
and make a different call if I have specific TLS/SSL needs;
- I'd consider it probably wrong to have a DialTLS with similar 'auto-sensing'  URL
behaviour, but an extra parameter for *tls.Config;  Esp., if DialTLS could create
a non-TLS connection by using a 'ws://' URL.
FWIW, the two protocol & origin parameters are not so much optional, as WS specific --
you don't _have_ to care what they are (tho Go kills an origin-less WS), but the
protocol considers them 'core' connection strings;
Ryans comment about allowing us to 'hijack' an existing net.Conn or http.ClientConn
would be a good thing to have regardless, and would've allowed (albeit with more work) a
similar end.
@adg
Copy link
Contributor

@adg adg commented Jun 20, 2011

Comment 6:

Labels changed: added packagechange.

Status changed to HelpWanted.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Jun 20, 2011

Comment 7 by ukai@chromium.org:

To support new hybi protocol, I'm thinking to change websocket.Dial to
 websocket.Dial(url string, config *websocket.Config)
and
 type Config struct {
    Protocol []string
    Origin string
    Version string
    ...
 }
so, *tls.Config may be a member of Config.
I also think of exporting NewClient.
What do you think of?
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Jun 20, 2011

Comment 8 by jdnurmi@qwe.cc:

Not sure what hybi is, but it seems pretty reasonable to me;
One thought though -- would it be better to use a *http.URL rather than parsing it
internally?  (Never been sure why so many functions that take URL's like strings myself,
since it's one more error to catch 'in-call')
Simultaniously, exporting a Handshake(*http.ClientConn, *proto.Config) might be useful .
@ukai
Copy link
Contributor

@ukai ukai commented Oct 7, 2011

Comment 10:

You can use websocket.DialConfig with config.TlsConfig
since weekly-2011-09-01
@rsc
Copy link
Contributor

@rsc rsc commented Dec 9, 2011

Comment 11:

Labels changed: added priority-later.

@lukescott
Copy link

@lukescott lukescott commented Jul 25, 2013

Comment 13:

If this is solved by DialConfig, shouldn't this issue be closed as Fixed? Unless I'm
missing something.
@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 14:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 15:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 16:

Labels changed: added repo-net.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 26, 2014

Comment 17:

This was fixed long ago: use DialConfig.

Status changed to Fixed.

@mikioh mikioh added repo-net and removed repo-net labels Dec 23, 2014
@mikioh mikioh changed the title go.net/websocket: client auth for outgoing connections websocket: client auth for outgoing connections Jan 4, 2015
@mikioh mikioh changed the title websocket: client auth for outgoing connections x/net/websocket: client auth for outgoing connections Jul 30, 2015
@mikioh mikioh modified the milestone: Unreleased Jul 30, 2015
@golang golang locked and limited conversation to collaborators Aug 5, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.