• Use the fingerprint to validate the certificate manually!

    23Feb
    Categories: sordid tales Comments Off

    You security people may write great crypto, but you have some serious communications problems.

    I recently updated my certificate at pamelaproject.com, and got the following error message upon attempting to commit code to subversion:

    OMG Certificate Issues!!!

    Being the owner of the domain, I know a few things:

    • If the subversion client had bothered to use PKI to validate this certificate, they would not be giving me this warning, because this certificate was issued by a trusted authority.  I know because I paid for it.
    • Since this subversion client never automatically validates the issuer of any certificate, the error message shown here is utterly misleading.    A more accurate error message would be to note that the certificate has changed; I doubt the software was doing anything that would warrant a stronger assertion.

    Still, I wondered — what would I do if this message popped up on the screen, and I actually took it seriously?

    According to the security message,  I should manually validate the fingerprint of the certificate before continuing.  How hard could it be to (a)  find out what that actually meant, (b) learn how to do it, and (c) actually verify my own certificate?

    Plan A: Hit the “help” button

    I clicked on the oh-so-convenient help button in netbeans. It didn’t tell me how to be secure, it simply told me the different ways in which I could make the error page go away. This gave me no satisfaction on points a, b, or c.

    Plan B: Google it

    I searched for combinations of ‘validate certificate fingerprint manually’.   The first hit was google asserting its own specific certificate fingerprint – didn’t help.  The next 6 pages of hits were various combinations of people asking for help or expressing frustration at this message.  I didn’t read all of these, but of the ones I did read, the answer given was to the wrong question.  People were advised on how to make the error screen go away, not how to ensure that the error was unfounded.

    So far, I still couldn’t even answer the simple question of what it means to manually validate a fingerprint.  Finally, deep in the search results, I found this:

    Google ResultsBuried in the page was this paragraph:

    …the key should be authenticated  manually by contacting the CA administrator and comparing the fingerprints of the certificate.

    This was the closest thing I have found to an explanation of what would have to happen in order for me to reach my goal.  It seems that I would have to contact the site admin, and have them tell me the actual fingerprint of the actual certificate so that I could visually confirm that the fingerprint shown in the error message was the same as the fingerprint of the site.

    Luckily in this case I am the site admin.  It’s hard to imagine that many people would refrain from using a their subversion client for the time it would take to identify and communicate with a site owner.  I also wonder whether if you were actually the target of a MITM attack, whether this means that DNS is poisoned and you couldn’t actually trust either email or a the same domain’s website page with a phone number.

    Not that we’re done yet:  How many site owners would know how to generate a fingerprint from their certificate in order to satisy a request from a user?  A bunch more searching got me to the point where I could generate an MD5 fingerprint with this command:

    $ openssl x509 -noout -fingerprint -in cert.pub
MD5 Fingerprint=0D:89:07:D6:4F:BC:84:2E:2E:14:C2:DA:D4:3B:D5:7C

    Brutal Conclusion

    Users are never going to jump through the hoops I just jumped through to obey the spirit of this message  and nobody on the software side cares whether users obey the spirit of this message either.  It doesn’t even matter that the meaning of the message was incorrect – because there is no obvious path to take that could actually result in users responsibly acting on any variation of the message.  This popup is nothing but an inconvenience with no security value whatsoever.

    Someday, somebody is going to win the Nobel Prize for making certificates usable.  I hope it happens soon.  They will have earned the distinction.

    Tags:

  • Silo Sync vs. Service Sync

    08Feb
    Categories: Provisioning Comments: 2

    Aha!  More fodder for discussion:

    …the identity information needs to be synchronized before the user performs his first authentication.

    Why?   Why must identity information be synchronized before the user performs the first authentication?  If a new employee has been provisioned an account at an IdP,  why shouldn’t that person be able to arrive at a Relying Party, and at that time have the IdP advise the Relying Party that (1) the user is valid, and (2) the user should be provisioned into the system?     I don’t see why my example from earlier can’t work in reverse — you batch update your incoming staff updates, but if they attempt to access the system before the batch job is accomplished, the IdP bundles a specific real-time provisioning request into the authentication, and the user is set up and granted access.

    To me, real-time back-end data synchronization is needed between silos.  Once you have a single Identity authority with a reach across administrative domains, and once you are doing more than testing possession of a shared secret, you have alternatives.  Perhaps not in every case – but in some cases, perhaps many cases.  Imaginative exploration of these new usage models are what makes this technology so much fun!

    Tags:

  • Federated De-provisioning

    05Feb
    Categories: Provisioning Comments: 3

    Provisioning,  you’re finally being hotly debated!!!   Can’t wait to add my own 2cents.

    Ian and Nishant, in debating differences/similarities between Enterprise Provisioning and Federated Provisioning, seem to be forgetting a critical difference between old-school provisioning and federated provisioning — the combination that federated provisioning provides of provisioning and AAA services coming from the same authoritative source and working in conjunction.

    For example, Ian and Nishant talk about federated de-provisioning:

    The second catch is deprovisioning. The provisioning process hinges on an authentication event. Deprovisioning cannot be activated on de-authentication. This does leave the problem of how to remove accounts when people have left a federation partner. In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login. After some period of time without an authentication, the account is suspended or deleted. Not a bad way to go.

    I would beg to differ.  Federated de-provisioning can be activated on de-authentication, in fact that is a major selling point!  There is no reason why an authority could not return a set of claims at the time a terminated user attempts to authenticate to the Relying Party that says (a) do not authenticate, and (b) de-provision immediately.   If the authority is set up to do so, the Relying Party is home free!  The urgent use case has been taken care of (ie abuse), and the non-urgent cases can be dealt with at leisure, because the associated risk is dealt with.  Who cares if it takes a month to actually delete the account, if you can guarantee that should the terminated user attempt to access the resource during that time, a real-time status check will occur and the termination will be discovered?    If a user is terminated and they never try to authenticate to the resource, maybe the account might last to the end of the day, or even the week.  Maybe the end of the month.   Then somebody can run a report, sync a directory, (god forbid) access a mass user management admin console,  run a cron job to do an out-of-band reconciliation, push a message via the ESB, whatever!  This part of the process can be messy in a federated environment, because the authentication and authorization mechanisms no longer exist in silos and can’t be fooled.  Or to be more exact, the real-time aspect of when the user must reliably disappear from the system no longer depends on security aspects, but rather content aspects dictate the business requires in the case where the user’s identity data is being displayed or acted upon by the system itself or by other users.

    I would also point out that most Enterprise systems are not going to be amenable to the expiry approach. Having your users disappear out of a system just because the haven’t logged in in a while is just too inexact a process.   Perhaps instead, the expiry date could kick off a workflow to verify the status of the user though.

    It’s ironic to think that batch processing could make a comeback – I’ve spent an awfully long time trying to get people out of that mentality :)

    Tags:

  • Which Selector will ship with Windows 7?

    04Feb
    Categories: Funny Things, MS/AD/InfoCards/CardSpace Comments Off

    WindowsSomehow, I was thinking of Windows 7 as being far far away, but apparently it could be here in as little as six months.  Now that details of what will ship under which SKU are starting to come out, I am dying to try and get the skinny from the Federated Identity team on whether Windows 7 users will get the old CardSpace bundled with .NET 3.5 sp1, or whether they will in fact get a bright shiny new CardSpace Geneva Selector!

    Kim? Mike? Don? Can you give us the scoop?

    As an aside, I hear that both fax services and full-image backup will be included in Windows 7 home edition — thank HEAVENS.   Whatever dim bulb removed those features from most/all of the the many and oh-so-confusing array of home versions in Vista caused me a WORLD of grief, in my capacity as reluctant amateur PC support for my family & friends.

    Photo attribution:  http://www.flickr.com/photos/marioraffin

    Tags: , ,

  • A Domain of my Own

    02Feb
    Categories: blog stuff Comments: 2

    Winter SunTada!  I’ve finally made the leap, and have transferred my blog from wordpress.com to my own web hosting site.   I’m now free to install whatever plugins I wish (and I bet you can guess what my plans are in that department).

    I would appreciate it if you could update your feeds and bookmarks to use my new URL:  http://eternallyoptimistic.com.  The old address will redirect you, but I would prefer to grab what little google-juice I might  :)

    If your feed stops working or links don’t work, or if you see things have gone awry, please drop me a line, either as a comment here, or using my contact form and I’ll set it right.

    Tags:

Disclaimer


These thoughts are mine. Everyone else can get their own blog.