<div dir="ltr"><div><div><div>Hello again!<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">There is nothing more permanent than temporary solutions in software.<br>

We cannot later tell our commercial customers "you know guys, that feature
that your app is built on, it was temporary. Good luck with upgrading!"<br></blockquote><br></div>Okay, agreed, now let me rephrase it then: this solution could be made permanent and marketed as an additional feature, so besides authenticating using the Websocket connect function, basic authentication via HTTP headers will also be available. :)<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">HTTPS should give you a reasonable protection from tampering and MITM.<br>
Making your credentials user-specific and "tokens" that you use to obtain "real" credentials ephemeral should protect reasonably well from malicious users.<br></blockquote><br></div>The thing that I don't like about this scheme is that a malicious end-user has the possibility of brute-forcing the rabbitmq user database by tampering with the client JS code running in his browser, as currently it's the only entry point where "real" credentials can be introduced. <br>
<br></div>Another issue with this approach is that a whole new server module is needed for handling ticketing, token generation, user access determination based on pulling data from rabbitmq user database or from LDAP, all of this adding unnecessary overhead to the entire design, and still not assuring proper security.<br>
<div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Your plan involves using basic HTTP authentication. How is this really<br>
more secure than using temporary tokens to programmatically obtain a pair
of credentials? <br></blockquote><br></div><div>In the design that I suggest, the weaknesses of the HTTP basic auth are irrelevant as the rabbitmq instance running Cowboy will be invisible to the outside world, and also the end-user has no direct access to the entry point where "real" credentials are introduced:<br>
</div><div><br>1. From client JS code any user/password can be introduced in the SockJS connect string, the exact values are totally irrelevant as these will be later overwritten, with no end-user possibility of influencing the process overwriting them;<br>
<br></div><div>2. The websocket HTTP handshake request reaches Nginx, which then takes the CN field from the client certificate, attaches it as a HTTP header to the request and forwards it to an internal rabbitmq instance, which is hidden from the outside world.<br>
<br></div><div>3. The Web-STOMP plugin overwrites the user-supplied values with those from the header before forwarding them to the STOMP processor for final authentication on rabbitmq.<br><br>4. ???????<br><br></div><div>
5. PROFIT!! <br>Authentication takes place completely transparently to the user.<br></div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">What were the exact steps you performed? R16B02 should be plenty sufficient for Cowboy and Rabbit. To build web-stomp, clone the umbrella, `make up` in it, then cd rabbitmq-web-stomp and run `make`.<br>
</blockquote></div><div><br></div><div>That's exactly what I did. Just tried it again, and still the same outcome:<br><br>../cowboy-wrapper/cowboy-git/src/cowboy_clock.erl: undefined parse transform 'eunit_autoexport'<br>
make: *** [../cowboy-wrapper/ebin/cowboy_clock.beam] Error 1<br></div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The Google group is just a way for start a conversation<br>

w/o signing up. Join rabbitmq-discuss proper.<br></blockquote><br></div><div>The problem seems to be that I joined the group from the Google Groups, and not from Rabbitmq site. I have now registered there, too, so hopefully this message will show up properly.<br>
<br></div><div>Thanks!<br></div><div class="gmail_extra">Andy.<br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 10:12 PM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br>
<br>
On 19 June 2014 at 19:47:28, Andrei (<a href="mailto:andrei002@gmail.com">andrei002@gmail.com</a>) wrote:<br>
> > Well it won't need that much support as the changes are minimal<br>
> and impact just a few lines of code in two source files, and also<br>
> it'll be just a temporary solution till proper support for SSL<br>
> client auth will be implemented :)<br>
<br>
</div>There is nothing more permanent than temporary solutions in software.<br>
We cannot later tell our commercial customers "you know guys, that feature<br>
that your app is built on, it was temporary. Good luck with upgrading!"<br>
<div class=""><br>
> > * It may also run into limitations in SockJS<br>
><br>
> What kind of limitations do you mean here?<br>
<br>
</div>I can't name any specific one without trying to implement the thing but<br>
I assure you APIs don't always provide exactly what you want :)<br>
<div class=""><br>
> > So I'd recommend combining HTTPS connection with credentials<br>
> obtained from an HTTPS endpoint in your JS application.<br>
><br>
> We have considered this approach, however the problem is that<br>
> the JS code initiating the websocket connection runs in the user's<br>
> web browser, and this makes such kind of solutions rather insecure.<br>
> On the other side using client certificate data for authentication<br>
> is both secure and happens completely transparently to the end-user.<br>
<br>
</div>HTTPS should give you a reasonable protection from tampering and MITM.<br>
Making your credentials user-specific and "tokens" that you use to obtain<br>
"real" credentials ephemeral should protect reasonably well from malicious<br>
users.<br>
<div class=""><br>
> So, I'd be very grateful if you could take a closer look at the solution<br>
> I've previously suggested and provide some hints on which changes<br>
> should be applied to the sockjs-erlang-wrapper and web-stomp<br>
> source in order to implement it.. unfortunately I'm having a<br>
> bit of a hard time figuring out where exactly to add that additional<br>
> HTTP header processing code..<br>
<br>
</div>Your plan involves using basic HTTP authentication. How is this really<br>
more secure than using temporary tokens to programmatically obtain a pair<br>
of credentials? <br>
<div class=""><br>
> Another issue I ran into playing with this is an error showing<br>
> up when trying to compile the original web-stomp plugin from<br>
> the rabbitmq-public-umbrella:<br>
><br>
> ../cowboy-wrapper/cowboy-git/src/cowboy_clock.erl: undefined<br>
> parse transform 'eunit_autoexport'<br>
> make: *** [../cowboy-wrapper/ebin/cowboy_clock.beam] Error<br>
> 1<br>
><br>
> Could you please shed some light on this? I've checked out the<br>
> latest rabbitmq-public-umbrella and my Erlang version is R16B02.<br>
<br>
</div>What were the exact steps you performed? R16B02 should be plenty sufficient<br>
for Cowboy and Rabbit. To build web-stomp, clone the umbrella, `make up` in it,<br>
then cd rabbitmq-web-stomp and run `make`.<br>
<div class=""><br>
> > P.S.: Although you have CCd rabbitmq-discuss group in the previous<br>
> messages, somehow these are not visible to me on the Rabbitmq-discuss<br>
> Google Group. Are there some viewing or access restrictions<br>
> set up?<br>
<br>
</div>The Google group is just a way for start a conversation<br>
w/o signing up. Join rabbitmq-discuss proper.<br>
<div class=""><div class="h5">--<br>
MK<br>
<br>
Software Engineer, Pivotal/RabbitMQ<br>
</div></div></blockquote></div><br></div></div></div>