Need for encryption in WSE 3.0 if using SS-avoid man-in-middle att

[John K]

Hello.

I plan on upgrading my .NET 2.0 web service to use WSE 3.0. I am using my
web service over SSL and the PC client application access the web service
directly (no middle man server(s)). I will be adding the UserNameToken
option to authenticate the user to the web service. I am considering adding
"usernameForCertificateSecurity" for additional security; even though I am
also using SSL. I am concerned about "man in the middle" attacks for both
the password and data being sent back and forth. How do I decide if SSL is
sufficient? Is the password sent in an encrypted format if I only use
"usernameOverTransport Security"? Is it possible for someone to find out the
password that the PC sends for authentication to the web service if I only
use "usernameOverTransport Security"? If it is possible to see someone's
password; what's a good way to verify the PC application is "talking" to a
valid server before it tries to authenticate by sending the user ID/Password?

 

[Dominick Baier]

SSL is not prone to MITM attacks. You don't need additional message based
security.

SSL also does server authentication by default. Before you send data, the
client checks the server certificate which has to be trusted and the common
name must match the DNS name portion of the URL.

http://www.google.com/search?q=how+...-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1

 

[John K]

The web address my PC client program goes to for the web services is editable
by the user. This is in case the customer wants to host the server side
components on their own server. Thus they need the ability to change the
address. Thus, some malicious user could change the address to some other
server with an SSL certificate. Then an unknowing, authorized user could
attempt to log into the web site with the PC client program, thinking its the
correct one since they don't know someone changed it (i.e. like a physical
key stroke logger hardware). The PC client program would then go to
authorize, unfortuantely to the wrong server; would then malicious server see
the user's password if I only use usernameOvertransportSecurity? I would
think the PC client would send the password unencrypted, but I am not sure if
it is still encrypted with that setting.

 

[Dominick Baier]

if the other endpoint has a trusted and valid SSL certificate, he would see
the data in cleartext.

But if you let customers change the endpoint address they must be also able
to change the server certificate for mutual authentication..so i don't see
a real advantage to use additional message security - and you are in the
same situation as with transport security.

Make sure that only authorized people (e.g. an admin) can change URIs on
the client.

 

[Steven Cheng[MSFT]]

Hi John,

If you only applied SSL/https as the transport channel and not use message
layer security feature in WSE, WSE will certainly send out the soap message
(include username/password credentials) in clearText format. However, I
think SSL/HTTPS should be strong enough for secure the mesages transfering
over the transport layer. If your concern is that some malicious one else
may redirect the request to a fake server with SSL/certificates, then you
can add codelogic in your client application to valiate the server
certificate exposed from the SSL/HTTPS server. The ServicePointManager
class in .net framework provide ServerCertificateValidationCallback event
that can let us add custom code logic to verify the server (which provide
the SSL/HTTPS service channel). And this event will occur at the initial
time when your webservice (or other webclient) which connect to HTTPS/SSL
server through .net webrequest components:


#ServicePointManager.ServerCertificateValidationCallback Property
http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
ercertificatevalidationcallback.aspx

#RemoteCertificateValidationCallback Delegate
http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
tevalidationcallback.aspx


Anyway, I also think that you can choose either
SSL/HTTPS(UsernameOverTransport) or message layer
security(UsernameOverCertificate), use both of them may be a bit redundant.

Please feel free to post here if you have any other concerns or ideas on
this.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[John K]

How do I perform mutual authentication; in particular, how can my application
verify it is talking to the right server before it tries to log into the web
service? Is this done with certificates (private on server and public
version of it on client)? I already have an SSL certificate from Verisign
for the server. Do I generate a "public" certificate based on that server
(private) certificate and then distribute it with the app and then the app.
verifies the certificates are for the same server? Is there an article with
an example on how to do this? I want to make sure I don't talk to a malicous
server and give it the password without first verifying it is a valid server.
Remember that my application needs the ability to change what server it
points to.

 

[Steven Cheng[MSFT]]

Hello John,

If you use WSE message layer security, the "mutualCertificate10" and
"mutualCertificate11" will both support mutual authentication againt both
server and client.

As for transport layer secruity through SSL/HTTPS, as I mentioned in the
last reply, you can add code logic in your webservice client and hook the
Server Certificate validation process to determine whether the https/SSL
server is a valid and expected server.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[John K]

Dominick said I don't need message level security since I am using SSL, thus
message level security adds unnecessary overhead. Is there a good way to do
mutual authentication at first connection to the web service so there is no
signficant overhead for message based security? Is there any "how to" or
examples on how to implement mutual authentication, ideally, without
requiring message based security? Finally, if I do need a client certificate
to do the mutual authentication; how do I generate a client certificate? Can
I generate a client certificate from a server SSL certificate (which my
server has) OR do I need another type of certificate on my server.

I know there are several questions here, but please answer each one.

 

[Dominick Baier]

SSL, thus message level security adds unnecessary overhead. Is there

a good way to do mutual authentication at first connection to the web
service so there is no signficant overhead for message based security?

thats _exactly_ what SSL is doing.

for client certificate authentication, simply require SSL client certificates
in IIS (directory security tab).

Finally, if I do need a client certificate to do the mutual
authentication; how do I generate a client certificate? Can I

You can use a public CA or Windows Certificate Services or makercert.exe

 

[John K]

SSL only validates you are talking to a SSL certified server; not necessarily
the "right" SSL certified server. We allow the client user to change what
URL the software uses for accessing web services. This is our customer wants
to host the server components of the system we are selling on their server(s)
instead of ours. Thus, we do not need to send a special version of the
software to the customer. They can simply edit the URL the client program
access.

Thus, I am wondering what is a secure way of verifying the client program is
talking to a "valid" server (the one with the acutal web services that need
to be accessed) BEFORE it sends the user's ID and password. I believe this
can be done by using a X.509 certificate on both ends, but I thought the adds
message level security which is overkill since we are using SSL. What do you
recommend for testing if the client program is talking to the "right" server
before it freely gives the user ID and password for authentication. Since we
allow the user to change the URL in the client program; a malicous user could
temporarily change the URL and then an unsuspecting user would attempt to log
in and when the S/W tries to do that; it would give the "malicious" server
it's password.

 

[Steven Cheng[MSFT]]

Hi John,

Yes, your concern that some malicious user may redirect the user to a fake
server is reasonable. However, this can be detected by SSL/HTTPS client in
almost every webclient implementation. For example, in IE browser, when
you visit a ssl/https protected site, if the server certificate is not in
your client machine's trust storage, IE will raise dialog to alert you and
only if you proof to continue will the https/ssl connection successfully
establish.

When you use .net network API(such as webservice proxy or webrequest class)
to access remote SSL/https service, there also exist programming interface
to do the validation. I've mentioned the
"ServicePointManager.ServerCertificateValidationCallback" event in my first
reply, is there any particular reason or difficulty that this is not
suitable in your scenario?

This event is firing everytime at the initialize time of a https/ssl
connection between client and server(when the client just receive server's
SSL certificate), you can query the certificate's attributes to determine
whether it is your expected one(this validation logic is up to you since
you know what certificate is expected ....). Surely, at that time, the
webservice hasn't send any message since SSL/HTTPS connection is even not
established, if you found that the server certificate is not expected one,
just return false for the function or even through exception.

Here is my original message in first reply
==============================
If your concern is that some malicious one else may redirect the request
to a fake server with SSL/certificates, then you can add codelogic in your
client application to valiate the server certificate exposed from the
SSL/HTTPS server. The ServicePointManager class in .net framework provide
ServerCertificateValidationCallback event that can let us add custom code
logic to verify the server (which provide the SSL/HTTPS service hannel).
And this event will occur at the initial time when your webservice (or
other webclient) which connect to HTTPS/SSL server through .net webrequest
components:


#ServicePointManager.ServerCertificateValidationCallback Property
http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
ercertificatevalidationcallback.aspx

#RemoteCertificateValidationCallback Delegate
http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
tevalidationcallback.aspx
=============================

Anyway, I think https/ssl the prefered approach if possible since it is
much simpler and strong for secure channel over http.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[John K]

The part that is confusing for me is the fact that we are allowing the user
to change the URL. Thus, correct me if I am wrong, in this scenario; in
order to detect we are connected to the wrong server (even though its SSL
certificate is OK and valid by Verisign); we would need a client certificate.
Correct? If so, as I asked in a few messages, how do I generate a client
certificate? Can I generate a matching client certificate from the server's
SSL certificate OR do I need another set of certificates (a client and
server)? Are there any articles that go into detail on how to verify you are
talking to the right server. Again, in my case my customer may host the
server application; thus when I write the client S/W; I have no idea as to
what server is valid. It sounds like verifying the public certificate at the
client end matches the server certificate is the way to go. Do you have any
tips to what to look for in the certificate's attributes in this scenario?
Do I simply verify my client certificate is the public version of the
server's certificate and thus that means I am talking to the right server?
Thus, the customer could simply just place the public version of the server's
certificate in our client application directory? Thanks alot. I am new to
this and just want to make sure I have a secure application.

 

[Steven Cheng[MSFT]]

Thanks for your reply John,

Well, now I understand the "client certificate" you mean, actually this
should be called "public certificate of the server SSL/HTTPS certificate"
(which only contains the public key to identitfy the server certificate).

Yes, you can import such a public certificate of server-certificate into
client machine's trusted storage so that the SSL/HTTPS server with the
correct server certificate can be identified. However, this is not
necessary because X509 certificate verification is based on certificate
chain, so the client can correctly validate the certificate as long as the
SSL/HTTPS certificate's CA's certificate is installed or any trusted super
path certificates is installed into trusted storage.

Also, even if your server certificate's public certificate is not
installed, you still have chance to validate the certificate yourself in
code. In .net you can use the
"ServicePointManager.ServerCertificateValidationCallback" propertyto
register such a callback delegate to check the certifiate your self, e.g

=========================
public static bool ValidateServerCertificate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
if (sslPolicyErrors == SslPolicyErrors.None)
{
if (certificate.GetPublicKeyString() == xxxxx)
{
return true;
}
}


return false;
}
=========================

You can refer to the following MSDN reference for detailed info:

#ServicePointManager.ServerCertificateValidationCallback Property
http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
ercertificatevalidationcallback.aspx


#RemoteCertificateValidationCallback Delegate
http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
tevalidationcallback.aspx

Please feel free to let me know if there is still anything unclear or
anything I missed.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[John K]

Hello Steven,

Is a X509 certificate, that you mentioned, a different certificate OR is it
part of the server's SSL certificate? I thought they were entirely different
things. --
Thank you.

 

[Steven Cheng[MSFT]]

Hi John,

X509V3 is a certificate type and this is the most poular standard used
currently. Therefore, almost all the certificates mentioned here are of
X509 certificate. Also, there're many different kinds of x509 certificates
according to their usage. And SSL certificate is one of them. This
certificate can be used to identiffy a SSL/HTTPS server which contains both
private and public key(installed on the server). For SSL client-side, you
can import the SSL server certificate's public certificate(only contains
public key that can use to identify the certificate). Such public
certificate can be get through export the server certificate on the server
machine(no include private key).


Windows 2000 or 2003 server has a certificate service, you can install it
and produce different kind of test certificate that can be used in your
local environment.

#Use Windows Server 2003 Certificate Services Web Pages
http://technet2.microsoft.com/WindowsServer/en/library/26453270-45e5-4ffb-9a
25-38a661b058241033.mspx

for more detailed information about PKI and x509 certificate ,you can also
consult in some security specific community or forum.

Please feel free to let me know if you have any further questions on this.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.