Encryption without Certificates

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

lozd - 14 Aug 2005 22:11 GMT

Hi,

I'm working on securing a test/trial web service and could do with some
pointers.

The web service (as it stands) only has one client, the two endpoints are
securred with both their firewalls and IIS restricting traffic to that coming
from each other's IP addresses on HTTP port 80. I'd like to incoorporate some
encryption of xml documents and possibly authentication between them but
preferably without using certificates. Is this possibly using WSE 2.0?

Failing that I've heard that using the SelfSSL IIS tool an SSL certificate
intended for test purposes can be created. Seeing as both client and server
computers are controlled is there any issue with exporting this certificate
to the client computer and using it for a commercial application (as both
endpoints are completely trusted I don't see the need for a CA)?

If this is possible any suggestions on how to do this would be greatly
appreciated.

Reply to this Message

SA - 15 Aug 2005 19:53 GMT

Hi,

William Stacey wrote an implementation showing how it's possible to encrypt
and/or sign data using WSE 2.0 without using certificates. You can find his
original blog entry here:
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!268.entry

I did find two issues with his implementation. The code as discussed /
revised in the second entry erroneously does require having the private key
on the client and also his utility functions don't set the SCT's expiry time
in UTC, which is required. I have a full sample implementation available at
http://www.adduxis.com/play/SecureUTSCTSample-VB.zip

HTH,

Signature

Sven.

> Hi,
>
[quoted text clipped - 15 lines]
> If this is possible any suggestions on how to do this would be greatly
> appreciated.

Reply to this Message

lozd - 16 Aug 2005 14:19 GMT

That should be a big help. At first glance it looks to be close to exactly
what I need. Thanks for pointing out the extra issues too.

Thanks!

lozd

> Hi,
>
[quoted text clipped - 33 lines]
> > If this is possible any suggestions on how to do this would be greatly
> > appreciated.

Reply to this Message

William Stacey [MVP] - 17 Aug 2005 16:42 GMT

Thanks for the info SA. I would like to correct any bug, but am confused.
The updated code, TMK, does not require any private key on the client side.
The first version created a new private/public key pair and sent the public
part in the message to the server so the server could use the public key to
encrypt a reply. The private key on the client side was only used to verify
the server's reply signature. This overhead, was kinda messy and not
necessary IMO, so I created the updated version to simplify that does not
require a key pair on client side. The updated version does *not use a
private key of any kind - only the public key. Also, the expire time is
always sent in UTC in both versions on the wire. It is converted to Local
time on both sides only when the respective tokens are created. IIRC, we
talked about that on the ng already. The SCT lifetime needs to be converted
and set to Local time (not UTC) because internally, the SCT uses Local time
to do the expire check. If you set it in UTC time, you will eventually have
problems ( IIRC, I needed to look at the SCT .Net code to figure that out.)
Given the above, I don't see any issues. If I am incorrect, please correct
me and I will make any required change(s). TIA

Signature

William Stacey [MVP]

> Hi,
>
[quoted text clipped - 39 lines]
>> If this is possible any suggestions on how to do this would be greatly
>> appreciated.

Reply to this Message

SA - 17 Aug 2005 18:42 GMT

William:

The problem with the private key may not appear exactly in your
implementation. I am not sure if you recall, but I use the private/public
key pair from an SNK file.

The specific issue was on the client side after receiving the SCT identifier
etc. back from the token issuer. Where you use the VerifyData() function on
the pubRSA object, I had to use the VerifyHash() function. VerifyData
apparently does require the private key to be loaded as well.

With the SCT, I experienced problems only in time zones east of the
meridian. The SCT was expired when it arrived at the client. That makes
sense, because of course in those time zones it is later than it is in UTC.
You would never notice this in time zones west of UTC, unless you actually
had a unit test that waited until the expected expiration of the SCT. I have
not had any problems with the SCT after this fix.

HTH,

Signature

Sven.

> Thanks for the info SA. I would like to correct any bug, but am confused.
> The updated code, TMK, does not require any private key on the client side.
[quoted text clipped - 21 lines]
> > his
> > original blog entry here:

http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!268.entry

> > I did find two issues with his implementation. The code as discussed /
> > revised in the second entry erroneously does require having the private
[quoted text clipped - 30 lines]
> >> If this is possible any suggestions on how to do this would be greatly
> >> appreciated.

Reply to this Message

William Stacey [MVP] - 18 Aug 2005 06:04 GMT

> The specific issue was on the client side after receiving the SCT
> identifier
> etc. back from the token issuer. Where you use the VerifyData() function
> on
> the pubRSA object, I had to use the VerifyHash() function. VerifyData
> apparently does require the private key to be loaded as well.

VerifyData() is just a helper function which computes the hash of data first
and then calls VerifyHash() internally. So VerifyData also calls
VerifyHash. It just does a couple steps in one call. So not sure what
issue you had with that. TMK, neither require that the RSA object also
contain a private key and would only use the public key part anyway.

> With the SCT, I experienced problems only in time zones east of the
> meridian. The SCT was expired when it arrived at the client. That makes
[quoted text clipped - 4 lines]
> have
> not had any problems with the SCT after this fix.

I am no time expert, but not sure about that. If the server picks a time in
the future, then converts to UTC and sends that to the client, the client
should be able to convert that UTC to local time (regardless of its time
zone) and have a local time in the future (as long as the time is far enouph
in the future to account for the lag time on the wire.). So you still
should not have had an issue as far as I can tell - unless something else
was going on at one of the machines. I do know, however, that the expire
calculation is done using a compare to DateTime.Now which is local time
based (not UTC based). So if you set the LifeTime using a UTC, you may get
unexpected expire results. If I am in error, please supply a specific time
example as I would be interested in seeing the issue. TIA

Signature

William Stacey [MVP]

Reply to this Message

C.Dimitrov - 15 Feb 2006 16:45 GMT

Hi, William

At first great article!
About the UTC timings, the only way I could figure out is to add
<timeToleranceInSeconds> on both client and server config files.

ms-help://MS.WSE20.1033/wse/html/aebed245-7f2c-4048-9477-9e2629c7ee5a.htm

Use the <timeToleranceInSeconds> element when there is a clock difference
between the SOAP message sender and receiver. WSE uses the
<timeToleranceInSeconds> element when it compares the current time against
the expiration time for all security tokens and against the creation time for
post-dated security tokens. The default time buffer is five minutes. That is,
WSE uses the <timeToleranceInSeconds> element to determine the time buffer of
when a security token or SOAP message is valid.

An example is Client code is at GMT+1 and Server code is at GMT-5

Best Regards,
C.Dimitrov

> > The specific issue was on the client side after receiving the SCT
> > identifier
[quoted text clipped - 29 lines]
> unexpected expire results. If I am in error, please supply a specific time
> example as I would be interested in seeing the issue. TIA

Reply to this Message

Encryption without Certificates

Free Magazines