We are evaluating feasibility of the following solution for Single Sign On.
Scenario.
Website domain. https://www.example.com
[SSL using multi-server wildcard certificate]
Hosted on Server 1.
Other portal. https://portal.example.com
[SSL using the same certificate (multi-server wildcard certificate)]
Hosted on Server 2.
Solution:
The intention is to share a cookie between the www.example.com and the portal.example.com subdomains, however, for this to work the SSL protocol needs to satisfy the following requirements:
Continue to block Man-in-the-middle attacks.
Encrypt/Decrypt in the same manner for both Server 1 and Server 2. So that they can get the same information from the cookie.
Question is: Is there any limitations in terms of private keys or the SSL protocol perse that will make the solution above not feasible?
Thanks,
Yes, your solution will work and will mitigate most MITM attacks provided the CA that your certificates are purchased from are trusted by the client browsers.
If the cookie is set with domain example.com it will be shared between www.example.com and portal.example.com. It is also advisable to set the Secure flag to make sure it cannot be transmitted over plain HTTP. I am assuming both www.example.com and portal.example.com both have a server-side mechanism to validate the cookie value to authorise each request.
RFC 6265 states:
The Domain attribute specifies those hosts to which the cookie will be
sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com.
The old RFC 2109 specified that you needed a . before the domain, however 6265 overrides this. This means if you want to share cookies and make it compatible with very old browsers you should set the cookie with domain .example.com rather than example.com. There is nothing to lose by doing the former as newer browsers will simply ignore the dot.
In your solution, both Server 1 and Server 2 will receive and be able to decrypt the cookie. Note there is not requirement for both servers to have the same certificate - they will both decrypt the SSL session independently using their installed private keys (or rather a shared symmetric key that is transmitted using their installed private keys - to be precise).
However, using a wildcard certificate for *.example.com will be cheaper as the same certificate can be installed on both servers.
Related
I'm reading the list of useful header from OWASP and I've some trouble understanding if the first two require an HTTPS certificate ?
Public Key Pinning Extension for HTTP : The Public Key Pinning Extension for HTTP (HPKP) is a security header that tells a web client
to associate a specific cryptographic public key with a certain web
server to prevent MITM attacks with forged certificates.
Strict-Transport-Security : HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This
reduces impact of bugs in web applications leaking session data
through cookies and external links and defends against
Man-in-the-middle attacks. HSTS also disables the ability for user's
to ignore SSL negotiation warnings.
HTTP Public Key Pinning(HPKP) is a trust on first use technique. When a user requests a web server for the first time, the server tells to pin its own or an intermediate CA’s public key to the browser via a special HTTP header. After that browser stores this key for a given period of time. Upon user’s subsequent requests for that web server, the browser expects to contain the pinned key inside one of certificates in the certificate chain of the web server. If not, the user is blocked by giving a warning. For more information you can refer Implementing and Testing HTTP Public Key Pinning (HPKP)
Yes they both do require a certificate:
The first one pin a list of certificates. One of the must be in the current certificate chain.
The second one force to use https if the current https connection is valid.
So by definition the first one need https and a certificate, and the spec of HSTS forbid to send the header with http connections.
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 am developing a Node.js app based on the Express framework. On the backend, I need to have servers talk to each other (ie. Server 1 make a request of Server 2).
Is it OK to forego a DNS A-Record and just use the IP address of the server?
In that case, how do I authenticate the server and "client" (aka server). I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
Using a IP might be more secure then DNS (e.g. no DNS spoofing), but it still allows ARP spoofing, e.g. some other computer claims to have this IP. And in case both computers are not in the same network there are also ways to hijack requests in routers etc.
The secure cookie is nothing else as a shared secret. And contrary to public key based authentication (e.g. using certificates) shared secrets have the disadvantage that you need to distribute them in a secure way so that nobody else gets access to them.
I don't think that your idea is easier to handle than SSL with certificates, so I don't see an advantage of making your own secure protocols. History tells us, that such homegrown protocols mostly provide worse security than established solutions.
If you don't care about security (these hosts are on your network, in which you have trust), don't bother with the homebaked cookies.
If you do care about security get (or generate your own) certificate and use SSL.
I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
This is not secure at all! Anybody situated on an appropriate network between the client and server can see that "secure cookie", as well as any subsequent communications. This would allow them to reuse that cookie themselves to impersonate either the client or server, and would expose any sensitive information sent in the exchange.
Use SSL. It has already solved all of these problems, and more.
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv
I have a website that came with a SSL site for HTTPS but its on a different server. Example being
my website:
http://example.com
my SSL site:
https://myhostingcompany.com/~myuseraccount/
So I can do transactions over HTTPS and we have user accounts and everything but it is located on a different domain. The cookie domain is set for that one.
Is there a way I can check on my actual site to see if a cookie is set for the other one? And possibly grab its data and auth a user?
I think this violates a major principle of security and can't be done for good reasons, but am i wrong? is this possible?
You can setup a service on either site to handle RPC via HTTP POST requests. You can make it require some sort of session that can only be created by your sites. However, whatever can be accessed over that shared session on the HTTPS site will have no guarantee of confidentiality or integrity.