I want to use secure websockets with socketio and nodejs so that more of my mobile traffic/corporate networks can utilise websockets.
What level of SSL certificate is required for most browsers to accept the certificate/server as trustworthy. Browsers don't have an interface for reviewing/allowing SSL connections for websockets as far as I know, so how do they handle a cert they don't trust? Do they just refuse the connection?
What minimum level is required from an example list: https://www.123-reg.co.uk/ssl-certificates/ and has anyone done any research into how browsers handle various levels of SSL in websocket connections?
Securing a websocket is no different to securing an HTTP connection. A TLS handshake process will happen first to establish a secure connection and then an HTTP connection will be established over this secure link. For a websocket the additional step of upgrading the HTTP session to a socket will be taken. What this means is that whatever works for HTTPS will work for WSS. This link has a useful diagram.
I'm not sure what the difference is between the "123 SSL" and "Domain SSL" levels in your link, if the lower cert is issued against your domain it may be fine. Generally you want "Domain Level Validation" or above - it is enough to secure traffic between clients and your server. As long as the root certificate is trusted (generally the company you are buying the certificate from), browsers will accept this with no message or warning. For WSS, APIs and communicating with mobile apps this will be fine. The top level certificate (Extended Validation or EV) has the added advantage of additional security indicators in the browser (usually the green address bar or lock), great for browser sites but not of much use for pure WSS or API clients.
Related
get.page says that .page domains require https
What differences do .page domains provide?
Why does ellen.page say Not Secure and show an error?
The reason you are seeing the “Not Secure” warning is because the web page or website you are visiting is not providing a secure connection. When your Chrome browser connects to a website it can either use the HTTP (insecure) or HTTPS (secure). Any page providing an HTTP connection will cause the “Not Secure” warning.
Hypertext Transfer Protocol Secure is an extension of the Hypertext Transfer Protocol. It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security or, formerly, Secure Sockets Layer.
The Hypertext Transfer Protocol is an Session layer protocol for distributed, collaborative, hypermedia information systems.
HTTPS is HTTP with encryption. The only difference between the two protocols is that HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. As a result, HTTPS is far more secure than HTTP. A website that uses HTTP has http:// in its URL, while a website that uses HTTPS has https://.
.page domains are different because they require HTTPS certificates.
ellen.page normally uses encryption to protect your information. When Google Chrome tried to connect to ellen.page this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be ellen.page, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
How do the web protection products which intercept SSL traffic using proxy, work with sites implementing SSL pinning?
Examples of web protection products which intercept SSL traffic -
Blue Coat Proxy SG
Sophos Gateway
McAfee Web Gateway
https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning :
Firefox and Chrome disable Pin Validation for Pinned Hosts whose
validated certificate chain terminates at a user-defined trust anchor
(rather than a built-in trust anchor). This means that for users who
imported custom root certificates all pinning violations are ignored.
In other words, for that kind of interception, SSL pinning is disabled, because the user agree to the interception (by installing a software / a certificate)
This might be silly question as I am very new to this. Please help me knowing the details:
I have only below information for a application:
1) Application is accessed using https through browser
2) Application talks to LDAP over SSL connection for authentication purpose
Now, my question is, if there would be some relation between SSL used by https and the SSL which application is using to communicate with LDAP?
Can we disable SSL so that application is accessed using http but the communication between application and LDAP is still over SSL?
There is requirement to change https to http because of some compatibility issue.
Thanks in advance.
Now, my question is, if there would be some relation between SSL used
by https and the SSL which application is using to communicate with
LDAP?
No, those are 2 different connections. In the first case the client is the browser and the server is your application and in the second case the client is your application and the server is LDAP.
Can we disable SSL so that application is accessed using http but the
communication between application and LDAP is still over SSL?
Yes, absolutely. Of course that would mean that the users passwords will be sent as cleartext between their browsers and your application. Depending on your scenario this could be acceptable but for a publicly facing website I would rather say that this is bad practice.
I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.
I'm reading a book on WCF and author debates about pros of using message-level security over using transport-level security. Anyways, I can't find any logic in author's arguments
One limitation of transport
security is that it relies on every
“step” and participant in the network
path having consistently configured
security. In other words, if a message
must travel through an intermediary
before reaching its destination, there
is no way to ensure that transport
security has been enabled for the step
after the intermediary (unless that
interme- diary is fully controlled by
the original service provider). If
that security is not faithfully
reproduced, the data may be
compromised downstream.
Message security focuses on ensuring the integrity and privacy of
individ- ual messages, without regard
for the network. Through mechanisms
such as encryption and signing via
public and private keys, the message
will be protected even if sent over an
unprotected transport (such as plain
HTTP).
a)
If that security is not faithfully
reproduced, the data may be
compromised downstream.
True, but assuming two systems communicating use SSL and thus certificates, then the data they exchange can't be decrypted by intermediary, but instead it can only be altered, which the receiver will notice and thus reject the packet?!
b) Anyways, as far as I understand the above quote, it is implying that if two systems establish a SSL connection, and if intermediary system S has SSL enabled and if S is also owned by a hacker, then S ( aka hacker ) won't be able to intercept SSL traffic travelling through it? But if S doesn't have SSL enabled, then hacker will be able to intercept SSL traffic? That doesn't make sense!
c)
Message security focuses on ensuring the integrity and privacy of individ-
ual messages, without regard for the network. Through mechanisms such
as encryption and signing via public and private keys, the message will be
protected even if sent over an unprotected transport (such as plain HTTP).
This doesn't make sense, since transport-level security also can use encryption and certificates, so why would using private/public keys at message-level be more secure than using them at transport-level? Namelly, if intermediary is able to intercept SSL traffic, why wouldn't it also be able to intercept messages secured via message-level private/public keys?
thank you
Consider the case of SSL interception.
Generally, if you have an SSL encrypted connection to a server, you can trust that you "really are* connected to that server, and that the server's owners have identified themselves unambiguously to a mutually trusted third party, like Verisign, Entrust, or Thawte (by presenting credentials identifying their name, address, contact information, ability to do business, etc., and receiving a certificate countersigned by the third party's signature). Using SSL, this certificate is an assurance to the end user that traffic between the user's browser (client) and the server's SSL endpoint (which may not be the server itself, but some switch, router, or load-balancer where the SSL certificate is installed) is secure. Anyone intercepting that traffic gets gobbledygook and if they tamper with it in any way, then the traffic is rejected by the server.
But SSL interception is becoming common in many companies. With SSL interception, you "ask" for an HTTPS connection to (for example) www.google.com, the company's switch/router/proxy hands you a valid certificate naming www.google.com as the endpoint (so your browser doesn't complain about a name mismatch), but instead of being countersigned by a mutually trusted third party, it is countersigned by their own certificate authority (operating somewhere in the company), which also happens to be trusted by your browser (since it's in your trusted root CA list which the company has control over).
The company's proxy then establishes a separate SSL-encrypted connection to your target site (in this example, www.google.com), but the proxy/switch/router in the middle is now capable of logging all of your traffic.
You still see a lock icon in your browser, since the traffic is encrypted up to your company's inner SSL endpoint using their own certificate, and the traffic is re-encrypted from that endpoint to your final destination using the destination's SSL certificate, but the man in the middle (the proxy/router/switch) can now log, redirect, or even tamper with all of your traffic.
Message-level encryption would guarantee that the message remains encrypted, even during these intermediate "hops" where the traffic itself is decrypted.
Load-balancing is another good example, because the SSL certificate is generally installed on the load balancer, which represents the SSL endpoint. The load balancer is then responsible for deciding which physical machine to send the now-decrypted traffic to for processing. Your messages may go through several "hops" like this before it finally reaches the service endpoint that can understand and process the message.
I think I see what he's getting at. Say like this:
Web client ---> Presentation web server ---> web service call to database
In this case you're depending on the middle server encrypting the data again before it gets to the database. If the message was encrypted instead, only the back end would know how to read it, so the middle doesn't matter.