[Code] Encrypting communication between the OP and the RP

Russ Ferrill rferrill at vendorsafe.com
Fri Apr 13 05:18:01 UTC 2012


Does the OpenID protocol require signing or does it just support it?
Does the DNOA implementation of OpenID implement signing by default? I assume that if the OP is signing the data that it sends to the RP, then the RP must be configured to use the same hashing algorithm and key as the OP. Can you tell me where these are set?
I'm using the WebRingSsoProvider and Relying Party. Do they use the same configuration parameters for hashing algorithm and key as for Forms Authentication? If so, then I know how to set those.
Can you tell me which OP method does the signing and which RP method checks the signature?
Thanks.

Russ

From: Andrew Arnott [mailto:andrewarnott at gmail.com]
Sent: Thursday, April 12, 2012 10:41 PM
To: Russ Ferrill
Cc: openid-code at lists.openid.net
Subject: Re: [Code] Encrypting communication between the OP and the RP

Hi Russ,

The attacks you mention are not prevented by encryption at all.  Signing is what protects against those attacks, and those are built into the OpenID protocol itself, so you don't even need SSL.  What SSL will buy you is privacy (which is not the same thing as user spoofing) and protection against a DNS poisoning attack, which is difficult, but possible in some cases.  DNS poisoning can potentially lead to user spoofing, so SSL is definitely worthwhile.  But you can protect against the user spoofing via DNS poisoning attack via SSL at the OP side -- the RP being SSL-encrypted is not critical to it AFAIK.  So as long as your RP is marked as requireSsl (which requires it of the remote party -- not itself) you're covered from that risk.

As far as risks have been discovered and that I know of, anyway.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Thu, Apr 12, 2012 at 7:56 PM, Russ Ferrill <rferrill at vendorsafe.com<mailto:rferrill at vendorsafe.com>> wrote:
Yes, I just want to be sure that nobody can intercept the communication between the OP and RP and cause the RP to believe that an unauthenticated user was actually authenticated or even to change the roles sent back for an authenticated user.

Is SSL sufficient for this?
Is there any stronger way to protect this data transfer?
Thanks.

Russ

From: Andrew Arnott [mailto:andrewarnott at gmail.com<mailto:andrewarnott at gmail.com>]
Sent: Thursday, April 12, 2012 7:51 PM
To: Russ Ferrill; openid-code at lists.openid.net<mailto:openid-code at lists.openid.net>
Subject: RE: [Code] Encrypting communication between the OP and the RP

As long as you don't mind the user who is logging in observing the data (not usually considered a problem) then SSL should be fine.  And yes, requireSsl=true is a good setting to enforce this.

Sent from my Windows Phone
________________________________
From: Russ Ferrill
Sent: 4/12/2012 1:05 PM
To: openid-code at lists.openid.net<mailto:openid-code at lists.openid.net>
Subject: [Code] Encrypting communication between the OP and the RP
Hello,

I am implementing an Open ID provider using the DNOA code. I want to be sure that the communication between the OP and the RP is secure. I'm only concerned about authentication requests and authentication responses. As far as I can tell from looking at the code this is all "indirect" communication accomplished by redirecting the end-user's browser. I want to be sure that the data included in the authentication request and the authentication response is encrypted. In order to accomplish this, do I have to do anything other than make the OP endpoint an https url protected by SSL? Would it be a good idea to set the require ssl configuration values to true? Is there anything else specific to the DNOA code that I need to configure or modify in order to support this?
Thanks.

Russ Ferrill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-code/attachments/20120413/7131296e/attachment-0001.html>


More information about the Code mailing list