so I'm currently trying to make an OpenID provider. I've tried using two Java based OpenID server packages- Atlassian's Crowd, and WSO2 Identity Server. Now, in my implementation, security is a must, which means using SSL and having HTTPS based OpenIDs. Now, for both WSO2 and Crowd a large number of sites simply do not work with the OpenIDs provided. Of 20 sites tested, 8 failed with Crowd, and 10 failed with WSO2. This high failure rate is not really acceptable. Virtually every site which has a problem claims that they cannot find an OpenID endpoint.
When I used the OpenIDs without SSL (so HTTP based OpenIDs) suddenly the sites were far more compliant, with only two of them failing. I am using a certificate from AusCERT, so the problem should not be due to self-signed certificates.
At first I thought that this was just a matter of there being a large number of RPs which simply did not accept HTTPS based OpenIDs. I tried logging into the same sites I was failing on with an HTTPS based OpenID from Verisign though, and it worked. Looking closer at both WSO2 and Crowd I discovered that neither completely conformed to OpenID 2.0 specification- in particular, neither of them provide a link in the head to an XRDS document for yadis discovery. Considering that my problem is that sites cannot discover an OpenID endpoint at the URL I give, it seems relevant except that when I do not use SSL the HTML based discovery is sufficient.
Does anyone have any insight as to where my problem really lies? The missing XRDS document seems like it should be relevant, but it could just be a red herring. Baring that, if anyone knows a good alternative to Crowd or WSO2 which is well documented, works well to spec, and is (relatively) easy to configure, it would be nice to know!
One thing to look at is that some Providers' SSL certificates are not signed by root authorities that are considered authoritative by some RPs. Make sure you get your certificate from one that all RPs trust.
If .NET is an option for your provider, check out the free and open source DotNetOpenAuth library, which you can host yourself and is used by some major OPs such as MySpace and netidme.com and others. It's implementation of OpenID 2.0 is complete, it supports the U.S. government ICAM OpenID 2.0 Profile, and has been used for many interoperability, security and compliance tests, and it works with both OpenID 1.1 and 2.0 RPs so you'd be very likely to have good interoperability with many/all RPs. It has a bunch of additional security features that you can just switch on (like requiring HTTPS as you said is a requirement).
(Full disclosure: I wrote DotNetOpenAuth.)
Related
I have two enterprise servers which need to communicate in a secure way, and am comparing using SSL (with client/server certs to validate both sides) vs two-legged authentication using OAuth 2.0 (optionally with MAC tokens or JWT tokens).
Historically OAuth seems to have been created for a totally different purpose (the 3-legged case where a user is allowing a service to access some data somewhere), and although two-legged is now integrated into the OAuth 2.0 spec, from what I have seen two-legged OAuth 2.0 doesn't seem to offer much additional protection over SSL.
The only point I can think of is that OAuth is potentially easier to configure than SSL, and it is easy to make mistakes with things like accepting bad SSL certs which can compromise security. However I am not sure if this is reason enough to go with OAuth.
Note that I mention these as separate options, but I think using OAuth would probably entail using it on top of HTTPS/SSL, so both would be used.
Is there any real advantage of using OAuth 2.0 two-legged scheme for server-to-server communication (no user involved)?
Note: I did find a a somewhat similar post here, but that is quite old but I don't feel that gave a satisfactory answer on this matter.
Apologies if you already know this but it isn't clear in your post.
OAuth and SSL\TLS are two separate layers of the OSI model. OAuth is for authentication and is at the top in Layer 7 while SSL\TLS is for transport security in layer 4. It's easy to confuse SSL with client certificates because they both use PKI.
You are correct in your understanding of OAuth...it is used for authorizing individuals not organizations\servers. 2-legged OAuth is a term that is thrown around which encompass various alternate OAuth flows, all of which do not follow a standard.
In my opinion, you want to use client certificates to secure your server-server communication...all that is really required is a single x509 certificate that can be used as both SSL (transport security) and client certificate (authorization); although using 2 certificates is the norm.
I'll respond to this comment:
My question is that, assuming I am using SSL with proper client/server certs to identify each machine, what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved). Thanks – Locksleyu
Summary: I wouldn't bother doing both.
Details: 2-legged OAUTH is only as secure as the consumer secret is. Similarly mutual auth SSL is only as secure as the private key. I assume that you'll be storing these in some encrypted store on each server. As both are stored in the same place I see no additional security that comes from adding OAUTH.
Now if you are considering a choice between mutual auth SSL and standard SSL with authentication, perhaps OAUTH can play a role there. I would go with whichever of those options seems easier. So if you have an OAUTH system in place and can easily add server auth to it, perhaps that's the way to go. Otherwise, just go with mutual auth SSL. It tends to be a bit of a hassle to configure but works well and quickly once set up.
To answer your question "what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved)."
You may refer below
https://salesforce.stackexchange.com/questions/93887/mutual-authentication-two-way-ssl-oauth
Hi guys this is my first time trying to handle Oauth in my project. I have read the tutorials on link. I have tried Google and Facebook Oauths and amazed by how simple it is. Now I am going to try Twitter / Yahoo / Microsoft just for learning purposes. This question might land me negative points as it is a learner question. So my question is when using Facebook Oauth you need the SSL Https URL for LocalHost machine. How about Yahoo/ Twitter/ Microsoft. Which one needs SSL.
When using OAuth, you should use SSL. As a matter of fact, Twitter requires SSL on all of their endpoints as of today. If you study the protocol, you'll see that there are tokens being passed back and forth in the Authorization header. You'll want to protect those. You also want protection on the responses from the provider, which contain tokens and other info. Some applications might not require SSL (though Twitter does now), it's best practice to be secure by design, secure by default, and secure in deployment.
No - your localhost machine does not need to be running SSL.
Indeed, even if you're not using localhost, there's no obligation to use SSL. Theoretically, there's little risk if your tokens do get intercepted, because your private tokens never leave your machine.
So, the OAuth dance can be
User -> Your Website -> SSL to OAuth provider -> Redirect to localost (non SSL)
I ask this because I work on an application where the X-AUTH-TOKEN can be copied from one request to another and impersonate another person. This makes me nervous, but I'm told since we're going to use HTTPS we don't have to worry about anything.
So, my question is: Is it good enough trust SSL to protect against stealing headers used for auth/sessions?
Thanks,
Using HTTPS encryption will indeed prevent someone from stealing your authentication token if they can intercept the traffic. It won't necessarily prevent a man-in-the-middle attack though unless the client enables peer certificate checking.
This question from the security stackexchange describes how to implement MITM attacks against SSL. If I can convince a client running HTTPS to connect to my server, and they accept my certificate then I can steal your authentication token and re-use it. Peer certificate validation is sometimes a bit of a pain to setup but it can give you a higher chance of whomever you are connecting to are who they say that are.
"Good enough" is a relative definition and depends on your level of paranoia. Personally I would be happy that my connection is secure enough with HTTPS and peer certificate validation turned on.
Presumably also your authentication token times out so the attack window would be time limited. For example the OpenStack authentication token is by default valid for 24 hours before it expires and then you are required to obtain a new one.
The HTTPS standard implements HTTP entirely on top of SSL/TLS. Because of this, practically everything except for the DNS query is encrypted. Since headers are part of the request and response, and only sent after the secure-channel has been created, they are precisely as secure as the implementation of HTTPS on the given server.
HTTPS is an end-to-end encryption of the entire HTTP session, including the headers, so on the face of it, you should be safe from eavesdropping.
However, that is only part of the story: depending on how the clients are actually connecting (is this a website or an API service?), it may still be possible to trick them into sending the data to the wrong place, for instance:
Presenting a "man in the middle" site with an invalid SSL certificate (since it won't be from a trusted authority, or won't be for the right domain) but convincing users to by-pass this check. Modern browsers make a big fuss about this kind of thing, but libraries for connecting to APIs might not.
Presenting a different site / service end-point at a slightly different URL, with a valid SSL certificate, harvesting authentication tokens, and using them to connect to the real service.
Harvesting the token inside the client application, before it is sent over HTTPS.
No one approach to security is ever sufficient to prevent all attacks. The main consideration should be the trade-off between how complex additional measures would be to implement vs the damage that could be done if an attacker exploited you not doing them.
im using silverlight 5 and WCF .. and the site is secured with HTTPS . however if i use fiddler , i can see this in the headers:
GET /ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
if i put that directly after my domain : https://www.mydom.com/ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
it will download all data from tabel users. how can i hide and protect this information from being visible!! isn't using SSL enought ? why is this visible anyways if im using https!?
thank you.
EDIT: my initial question was kind of an 'uneducated' one and for that i apologies,
i found more info on the subject and did more research. in this Q on SO there is an explanation to why fiddler is able to decrypt and view requests and responses sent over https.
What is point of SSL if fiddler 2 can decrypt all calls over HTTPS?
and to make things even more difficult, the common solution to this problem is using
"Certificate Pinning"
which requires the use of System.Net.ServicePointManager which is not included in the silverlight implementation of System.Net namespace.
so here i am stuck with an SSL cert. that i paid for that can be "cracked" by anyone with basic knowledge of web debugging.
From a purely Theoretical Computer Science point of view, what you are asking for is near impossible to actually impossible. You would need to implement a trusted platform to protect against the attack.
Now for the Science bit, Concentrate
Okay, so lets start with some basic theory. SSL and thus by extension HTTPS solves a very very specific problem. How do you communicate information over an unsecure NETWORK confidential information with a party you have never communicated with before. In this case, the emphasis is on NETWORK. It does so by solving two problems,
Authentication of the server (the server is who it says it is)
Asymmetric Encryption of key exchange
There is some overlap, to ensure that this is one step. I will focus on the 1st, as this is where fiddler "attacks" your system.
The SSL authentication works on a concept of a web of trust. Your computer has a list of TRUSTED verifiers. These are companies like Verisign, Thawte, Geotrust etc. These companies verify certificates by signing them (complex asymmetric encryption term, but its very like a handwritten signature, hard to forge, easy to verify).
Fiddler works by inserting a new trusted CA (verifier) into your computer. From then on, when you visit an HTTPS site, it will send requests on your behalf, reads it then forwards it back on to you with its OWN SIGNATURE. Since your computer completely trusts this signature, it thinks nothing is wrong.
Now, you want to implement certificate pinning. This IMHO is "bloody awful". It works by telling your software to expect a specific SSL cert. Two reasons why this is bad.
If I can work Fiddler, I can work dotPeek and recompile WITHOUT certificate pinning.
When your certificate gets revoked, your clients won't be able to connect.
Why would your certificate be revoked? If your CA loses their private keys, then they will be obliged to make sure its revoked and a replacement sent to you. Also each and every certificate has a sell by date as well, and must be replaced before they start to smell.
So finally what can you do?
SSL is NOT designed for protecting against what you are doing on your machine. The simpliest way to do what you are asking is to simply wrap your WCF calls in an extra layer of symmetric (or even asymmetric) encryption. But once again. The keys must live somewhere, so your client WILL be able to get the keys from a simple disassemble of your binaries and be able to construct a proxy of their own.
In conclusion
This is pretty much exactly the same as the DRM problem. You want to give your customer access to something on their machine but not show them how it works. If you do manage to solve this problem, do post a follow up, since Sony, Nintendo and Microsoft (to name a few) would be very interested in your findings.
Does anyone know of a project / product that has standardized how to access/download x509/SSL certificates over HTTP? I have seen RFC 4387 but haven't found anyone who implements it. Basically, I am trying to setup a key server for an internal application.
So short of implementing my own, does anyone have any suggestions?
That is the only "standard" for an HTTP-accessible certificate repository, but I've never seen it implemented. Most CAs that provide an HTTP repository do not use a standard, machine-accessible interface. For example, Verisign provides a certificate repository for certificates it issues to US government employees, and makes it accessible through a form-based web application.
For a machine interface, "everyone" uses LDAP. More importantly, while LDAP-enabled clients are common, I've never seen a client application that supported an HTTP interface. What do you plan to do with an HTTP repository?