I have a requirement where the present zqromq md5 authentication method has to be moved to curve authentication method. However there can still be clients using the old md5 authentication method in the topology. That means some clients will keep supporting older md5 authentication method whereas some clients will upgrade to the new curve authentication method. So is it possible for an zeromq server to set ZMQ_TCP_MD5SIG and ZMQ_CURVE_SERVER as well on the same socket (this happens to be a ZMQ_ROUTER socket)?
Answering my own question here. So the authentication method is configured per socket and not on zmq context. So one router socket can be configured as MD5 authenticated and the other router socket can be configured to use CURVE authentication. Both options can't be enabled on the same socket. So this two sockets and two ports respectively.
Related
I'm building out a Spring 4.2 based, WebSocket + SockJS + STOMP server, and I'd like to be able to get a reference to the WebSocketSession instance using the ws sessionId.
I can create a session manager myself by adding a WebSocketHandlerDecorator that registers new WebSocketSession's as their connections are established (and de-register's on close), but... this seems like something that Spring would already have created in the app context.
Does such a bean/service exist already?
Some background:
My main use case is a security concern. I am performing authorization on a per STOMP message basis, and an unauthorized message should result in the closure of the associated WS. I can intercept the messages and perform authorization, but at the moment I can't get a reference to the WebSocketSession in order to close it.
Second use case; after a successful web socket connection is made, my protocol expects a STOMP CONNECT within X seconds, or again I need to close the underlying WS connection. This one is slightly more interesting since it is asynchronous/timed and doesn't have any natural context like a message interceptor has.
All thoughts and suggestions appreciated.
EDIT
Indeed, Spring's SubProtocolWebSocketHandler class maintains a sessionId to WebSocketSession map, but all access to that map is private.
EDIT
There is support for tracking Users, Sessions, and Subscriptions at the STOMP level. This was added in version 4.2 and isn't documented in the chapter on WebSockets. (It's mentioned as a bullet point under "what's new".)
There is a SimpUserRegistry interface which provides the ability to get a user by name or a set of all users. These are SimpUser instances, which expose access to that user's sessions as a SimpSession either by a session id or as a set of all sessions for that user. From that you can obtain a set of SimpSubscription instances that represent STOMP subscriptions.
Per the javadoc, this should also work in a clustered (relay broker) environment.
Note for future readers, the SimpUserRegistry assumes that you've authenticated a user at the HTTP level, and that said user is defined by the request Principal. If you find yourself with an empty user registry, even though you have good STOMP connections, then you may not be authenticating the way the code wants.
See the last section of authentication under web sockets:
Note that even though the STOMP CONNECT frame has "login" and
"passcode" headers that can be used for authentication, Spring’s STOMP
WebSocket support ignores them and currently expects users to have
been authenticated already via HTTP.
All of the above still preclude access the the underlying web socket session, with it's close() method. I suspect my adoption on WebSocket's is a bit early, and that what I'm seeing is good support at the upper layer protocol (STOMP) level, but less fully fleshed out support for customization at the lower Web Socket layer.
I'm still looking for a way to affect the lower level Web Socket connection based on upper level activity, like non-authorized messages or failure to CONNECT after a TTL.
I want a bit of clarity on whether HTTPS is stateful or stateless? This is with regards to a RESTful API I built. We were initially using HTTP. Since HTTP essentially works over TCP/IP which is stateless hence HTTP is stateless, but when I switched to HTTPS my API became stateful. I wanted to know whether my conclusion that HTTPS is stateful. is correct or not?
I created my API using a middleware tool called webMethods.
Thanks
TLS/SSL is stateful. The web server and the client (browser) cache the session including the cryptographic keys to improve performance and do not perform key exchange for every request.
HTTP 1 is not stateful. HTTP/2 however defines many stateful components, but the "application layer" still remains stateless.
TL;DR: The transport pipe (TLS) is stateful, original HTTP is not.
Additional note: Cookies and other stateful mechanisms are later additions defined in separate RFC's. They are not part of the original HTTP/1.0 specification, although other stateful mechanisms like caching and HTTP auth are defined HTTP 1.1 RFC and RFC 2617. HTTP 1 is said to be stateless although in practice we use standardized stateful mechanisms. HTTP/2 defines stateful components in its standard and is therefore stateful. A particular HTTP/2 application can use a subset of HTTP/2 features to maintain statelessness.
Theory aside, in practice you use HTTP statefully in your everyday life.
The S in HTTPS is concerned with the transport, not the protocol. The semantics of the HTTP protocol remain the same for HTTPS. As the article about HTTPS on Wikipedia states,
Strictly speaking, HTTPS is not a separate protocol, but refers to use of ordinary HTTP over an encrypted SSL/TLS connection.
And the HTTP protocol is stateless by design, not because it is used most frequently over TCP/IP (nothing stops you to use HTTP over UDP for example).
HTTPS is HTTP over a secure connection.
HTTP is a higher level than a connection.
When connecting to a web server, your connection is (maybe always?) of type TCP/IP. So, in case you are visiting a website via HTTPS, your TCP/IP connection is encrypted.
The data the server and/or client send has not been encrypted by the server and/or client. It is just sent, as it is usually via HTTP, but this time using a connection via TCP/IP that is secured via encryption.
If data were vehicles, and the connexion the highway, then:
- using HTTP would be like the vehicles going on the highway, and everyone can see them;
- using HTTPS would be like the same, but the vehicles go through a tunnel or anything that prevents people not on the highway from seeing them. You can determine there is trafic, but you cannot identify the vehicles, except on both ends of the tunnel.
I believe this is an image close to what happens behind the scene. But I'm no expert. I just hope it helps.
HTTP and HTTPS both are stateless protocols. The S in HTTPS stands for Secure and it refers to use of ordinary HTTP over an encrypted SSL/TLS connection.
Use of JWT tokens or the traditional way of establishing sessions using cookies help us to overcome the problem of HTTP being a stateless protocol, as it enables the server to authenticate the identity of the client, so that you don't need to login every time you click a link to navigate on the web-page.
So For example, when you log in to the website of your bank, it only asks you to enter your login details once. Once you are signed in, you don't need to re-enter them when you navigate to the account settings page, this is because the bank site is able to authenticate your identity using JWT tokens.
JWT tokens are only used on HTTPS and not in HTTP, because the connection is encrypted in HTTPS, so it cannot be intercepted by anyone.
Thus, HTTP and HTTPS both are stateless protocols, but JWT Tokens provides a workaround for it.
I believe HTTPS is a stateful protocol as it contains Session identifier field.This generated by server initially to identify a session with the chosen client.
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them. "ws:"
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Here are my random stabs in the dark
Applets sockets provided by Java (need java installed)
Flash sockets provided by Flash (need flash installed)
But about HTML5, Why are they called WebSockets if they aren't Sockets?
Is the websocket protocol so simple to implement that it is "almost"-sockets?
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them.
[Is the] websocket protocol so simple to implement that [it is] "almost"-sockets?
Allowing regular socket connections directly from the browser is never going to happen because it opens up a huge risk. WebSockets is about as close to raw sockets from the browser as you are going to get. The initial WebSockets handshake is similar to an HTTP handshake (allowing web servers to proxy/bridge it) and adds CORS type security. In addition, WebSockets is a message based transport (rather than streaming as raw TCP) and this is done using a two byte header on each message frame.
Even flash is not able to quite make raw TCP connections. Flash sockets also add CORS security, but instead of an in-band handshake, flash socket connections make a connection to port 843 on the target server to request a security policy file.
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Yes, you can use my websockify bridge/proxy which allows a WebSockets enabled browser to connect directly to a TCP socket via websockify.
But about HTML5, Why are they called WebSockets if they aren't Sockets?
WebSockets are a transport built on TCP sockets. After the handshake there is very minimal overhead (typically just a two byte header).
I can't improve on Kanaka's answers to your secondary questions, and I know this question is a year old. But for the main question, Is there any way of doing a pure socket connection from a web browser, to enliven webpages? There is a project called the Java / JavaScript Socket Bridge that might be what you (or anyone coming across this page from a Google search) are looking for. The advantage of this method over what others have mentioned is that it does not require either a client-side or a server-side service to be run. So, for instance, if you wanted to implement an IRC client purely in JavaScript but your web host does not allow you sufficient rights to proxy the connection, this Java applet would be the way to go. The only concern is making sure the client has Java installed and allowed.
You can just send data between a client and a server with WebSockets. Simply speaking, the only difference that WebSockets introduces is that the client:
adds some header bytes, like the type of data and the length
adds masks and encodes the data using them
The server also has to add header bytes, but does not need to encode the data.
If you implement the protocol correctly (server side, that is, since the browser already has an implementation), you can use it with ease to send text and binary data. (Although browser support is narrow, especially for the latter.)
The benefit of WebSocket is that it is HTTP based. You can use it also in environments there http proxies are used. Thus Websocket has a higher infrastructure compatibility as plain tcp.
Additionally http/WebSocket is providing you some features which you otherwise have to specify on your own:
Redirect
NAT keepalive
Multiplexing via URI
Framing
If you are asking for some data to be pushed from server it is widely termed as COMET or Reverse Ajax.
Web sockets is still not very popular as there are inherent firewall issues and minimal support yet from popular browsers.
You can take a look at http://www.ape-project.org/ as this is one of the most popular implementations (but native to unix/linux only for now. For windows they suggest using a virtual box or vmware based implementation)
I wanted to understand the mechanism of message encryption and signing used by NetTcpBinding when 'Windows' credentials are being used with Transport security. What if my AD uses NTLM instead of Kerberos? Will the messages still get signed and encrypted?If so, how?
Thanks in Advance,
Akshat
The short answer is that, yes, with NTLM authentication the messages will still get signed and encrypted if you have set the Transport security ProtectionLevel to EncryptAndSign (the default).
Here's an outline of how it works:
selecting Transport security
configures a
WindowsStreamSecurityBindingElement
in the channel stack. This inserts a
stream upgrade provider (see below)
in the NetTcpBinding, message
exchange between the client and
service happens within the .NET Message
Framing Protocol, which provides both
message framing and a mechanism for
client and service to negotiate
stream upgrades, the principal use of
which is to establish transport
security. If there is a stream
upgrade provider configured in the
channel stack, this will be invoked
during the Preamble stage of the
Framing Protocol when the client
opens the channel.
the upgrade
provider for
WindowsStreamSecurityBindingElement invokes an SSPI handshake between the client and the server using the SPNEGO security package: in the NetTcpBinding this will normally result in Kerberos being selected as the underlying security provider if available, but will choose NTLM if not.
if NTLM is the resulting authentication provider, the SSPI handshake will involve the three-leg NTLM challenge-response exchange of tokens described in the NTLM specification. This protocol includes a mechanism for exchanging keys for message signing and encryption. Once the SSPI handshake has generated an appropriate security context, thereafter all messages exchanged are signed and encrypted in the sending channel stack's stream upgrade provider, and decrypted and verified in the receiving channel stack's stream upgrade provider, in each case by using calls to the NTLM security provider via the abstracted SSPI message support functions.
This is a Microsoft propriety implementation and not properly documented and perhaps on purpose to prevent intruders to take advantage of it.
As far as I know, this usually happens at the TCP level with a special token is generated by the user's credentials and passed along with the request. This is intercepted by windows security channel and authenticated against the AD.
This token is used as a key (or as a basis for generating the key) for encrypting the communication.
I think if you look at the TCP packet, you must be able to see the token - although I have never seen it.
If you are doing this all in code then you can find out the options here (search for 'NetTcpBinding'). Transport security is via Windows builtin TLS.
The diagram here should be helpful for your scenario.
A Web Socket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure Web Sockets over SSL can leverage the same HTTP CONNECT technique. [1]
OK, sounds useful! But, in the client implementations I've seen thus far (Go [2], Java [3]) I do not see anything related to proxy detection.
Am I missing something or are these implementations just young? I know WebSockets is extremely new and client implementations may be equally young and immature. I just want to know if I'm missing something about proxy detection and handling.
[1] http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket
[2] http://golang.org/src/pkg/websocket/client.go
[3] http://github.com/adamac/Java-WebSocket-client/raw/master/src/com/sixfire/websocket/WebSocket.java
Let me try to explain the different success rates you may have encountered. While the HTML5 Web Socket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a Web Sockets gateway or server.
The Web Socket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a WebSocket Secure connection, respectively. Both schemes use an HTTP upgrade mechanism to upgrade to the Web Socket protocol. Some proxy servers are harmless and work fine with Web Sockets; others will prevent Web Sockets from working correctly, causing the connection to fail. In some cases additional proxy server configuration may be required, and certain proxy servers may need to be upgraded to support Web Sockets.
If unencrypted WebSocket traffic flows through an explicit or a transparent proxy server on its way the WebSocket server, then, whether or not the proxy server behaves as it should, the connection is almost certainly bound to fail today (in the future, proxy servers may become Web Socket aware). Therefore, unencrypted WebSocket connections should be used only in the simplest topologies.
If encrypted WebSocket connection is used, then the use of Transport Layer Security (TLS) in the Web Sockets Secure connection ensures that an HTTP CONNECT command is issued when the browser is configured to use an explicit proxy server. This sets up a tunnel, which provides low-level end-to-end TCP communication through the HTTP proxy, between the Web Sockets Secure client and the WebSocket server. In the case of transparent proxy servers, the browser is unaware of the proxy server, so no HTTP CONNECT is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if Web Sockets Secure is used. Using encryption, of course, is not free, but often provides the highest success rate.
One way to see it in action is to download and install the Kaazing WebSocket Gateway--a highly optimized, proxy-aware WebSocket gateway, which provides native WebSocket support as well as a full emulation of the standard for older browsers.
The answer is that these clients simply do not support proxies.
-Occam
The communication channel is already established by the time the WebSocket protocol enters the scene. The WebSocket is built on top of TCP and HTTP so you don't have to care about the things already done by these protocols, including proxies.
When a WebSocket connection is established it always starts with a HTTP/TCP connection which is later "upgraded" during the "handshake" phase of WebSocket. At this time the tunnel is established so the proxies are transparent, there's no need to care about them.
Regarding websocket clients and transparent proxies,
I think websocket client connections will fail most of the time for the following reasons (not tested):
If the connection is in clear, since the client does not know it is communicating with a http proxy server, it won't send the "CONNECT TO" instruction that turns the http proxy into a tcp proxy (needed for the client after the websocket handshake). It could work if the proxy supports natively websocket and handles the URL with the ws scheme differently than http.
If the connection is in SSL, the transparent proxy cannot know to which server it should connect to since it has decrypt the host name in the https request. It could by either generating a self-signed certificate on the fly (like for SSLStrip) or providing its own static certificate and decrypt the communication but if the client validates the server certificate it will fail (see https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy).
You mentioned Java proxies, and to respond to that I wanted to mention that Java-Websocket now supports proxies.
You can see the information about that here: http://github.com/TooTallNate/Java-WebSocket/issues/88
websocket-client, a Python package, supports proxies, at the very least over secure scheme wss:// as in that case proxy need no be aware of the traffic it forwards.
https://github.com/liris/websocket-client/commit/9f4cdb9ec982bfedb9270e883adab2e028bbd8e9