Secure SOAP Server & Two way SSL authentication in 7.10

Hi,

I am trying to get the following example working in VW7.10 taken from
http://www.cincomsmalltalk.com/main/2013/01/sioux-new-framework-to-build-http-servers/, shown below. My Hello responder is a SOAP responder.
I have some difficulties getting it working without changing the framework.
Also I want to do 2 way SSL authentication at server side, I am wondering how to configure that in the TLS framework?

The issues I encountered are:
In the example the parameter aRSAPrivateKey implies a Security.X509.X509RSAPrivateKey, the only way I got it working is with a Xtreams.BCryptPrivateKey, is the TLS framework still a work in progress?
HttpsConnection by default resolves to Net.HttpsConnection. This is not compatible with a non positionable stream like the TLSRecordReadStream.
If I resolve use SiouX.HttpsConnection it is not compatible with SOAP marshaling.

For 2 way SSL authentication a CertificateRequest should be sent, the TLS handshake apparently does not allow it to be sent from the server.
CertificateVerify message is not implemented.

How do I get below sample working with SOAP without altering the framework considerably?

Christiaan

            server := Server new

addResponder: Hello new;

yourself.

                listener := server listenOn: 8001 for:

                HttpsConnection.

                certificates := TLSCertificateStore newWithDefaults

                                                known:

                                                anX509Certificate;

                                                certificate:

                                                (Array with:

                                                anX509Certificate) 
                                                key:  aRSAPrivateKey;

                                                yourself.

                serverContext := TLSContext newServerWithDefaults

certificates: certificates;

 yourself.

                listener tlsContext:  serverContext.

                clientContext := TLSContext newClientWithDefaults

certificates: certificates;

yourself.

                client := HttpClient new.

                client tlsContext: clientContext.

                server start.

                [ client get: 'https://localhost:8001/hello'.

                ] ensure: [

                                server ifNotNil: [ server release ].

                                client ifNotNil: [ client close ].

                                certificates release.

                                clientContext release.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Jerry,

Thank you for your response, I was afraid of your answer.
I really needed two way SSL authentication now, so I have extended the
framework to support it, and it is working.


However I still can not get the SOAPResponder, which is a subclass of
the the NetHttpResponder to work with the TLSRecordReadStream. If I use
HttpsConnection in the example it resolves to Net.HttpsConnection which
works with SOAP marshaling but not with the TLSRecordReadStream. The
SiouX.HttpsConnection works with the TLSRecordReadStream but the SOAP
marshaling breaks.

Is there  a way of making the SOAPResponder work with the
TLSRecordReadstream, without changing the framework or am I doing
something wrong?



Regards,

Christiaan



On 8-11-2013 20:14, Jerry Kott wrote:
> Christian,
>
> TLS client authentication is in our plans, but it's not available. So
> yes, it is still a work in progress.
>
> Jerry Kott
> Smalltalk Development

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Tamara,

Thank you for your offer, below is the code I am working on.
As described earlier I have the TLS working for me and does not give any
issues any more.  I am still in the process of implementing signature
verification of the TLSCertificateVerify(code=15) message but it is not
needed for a successful two way SSL authenticating handshake. (I believe
it should raise an error of the signed digest is not correct, but I
still have to read the specification in more detail to verify this)

I can not get this working without building my own SOAPResponder class
and HttpRequest class, but I would assume that the framework provided by
Cincom would work out of the box with TLS.

myCertificateStore is filled outside of this context.
I am using an external WsdlClient to test the implementation. This is
wsdl client  has been used in production and works with VW771 web
service implementation, .NET and java web services, all doing 2 way SSL
authentication.
It crashes on trying to call atEnd to the non-positionable
TLSRecordReadStream if I use SiouX.HttpsConnection, the
Net.HttpsConnection does not have a listener it seems.

My focus is getting the SOAP framework to work out of the box with TLS.
I have attached the stack of what happens when I try to handle a SOAP
request.

| listener serverContext |
     webService ifNotNil: [webService stop].
     webService := SiouX.Server new.
      Soops.PMB.ExternalInterface.PMBExternalInterfaceResponder
initializeResponders do:
                     [:responder |
                     webService addResponder: responder]].
    listener := webService listenOn: 8543
                         for: SiouX.HttpsConnection.
"tlsVerifier block is only needed for 2 way SSL authentication for this
example it is not relevant"
             listener tlsVerifier: [:certificate :connection |
     connection certificates known
         anySatisfy: [:cert | cert isSameAs: certificate]].
             serverContext := (Xtreams.TLSContext newServerWithDefaults)
                         certificates: myCertificateStore;
                         yourself.
             listener tlsContext: serverContext.

     ^webService


Christiaan


On 11-11-2013 19:36, Kogan, Tamara wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Christiaan Nooteboom"<[hidden email]> wrote:
> Thank you for your offer, below is the code I am working on.
> As described earlier I have the TLS working for me and does not give any
> issues any more.  I am still in the process of implementing signature
> verification of the TLSCertificateVerify(code=15) message but it is not
> needed for a successful two way SSL authenticating handshake. (I believe
> it should raise an error of the signed digest is not correct, but I
> still have to read the specification in more detail to verify this)

Adding client authentication is going to be tricky (part of the reason why it's not done yet). The tricky part is the CertificateVerify digest computation. It's different from the handshake digest computation, so you either have to run another parallel digest computation or you have to cache all the handshake messages (which the handshake digest computation carefully tries to avoid) and compute it from that (once you know what digest construct you have to use). Moreover the definition of the digest changes between the four supported versions of the protocol and may actually call for different approach. The good news is that the server knows upfront whether it will require the client to authenticate, so servers that don't want that can avoid all the overhead.

> I can not get this working without building my own SOAPResponder class
> and HttpRequest class, but I would assume that the framework provided by
> Cincom would work out of the box with TLS.

There really shouldn't be a problem here. SiouX supports NetHttpResponder over TLS out of the box. Try the following:

* Load TimeServerDemo
* Execute: TimeResponder addToServer
* Open the SiouX console (from SiouX-Tools) and modify the server created by the previous step to use HTTPS (in the Listeners sub-tab)
        (Note that if you don't specify the cert and key, the tool will offer to autogenerate one for you)
* Open a web browser and point it at https://localhost:4444/11/TimeNowService
* Proceed through browser's obligatory complaint about the autogenerated cert
* You should get the following back in response:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>
Unknown operation for GET request. Provide SOAP action header for the operation
</faultstring>
<detail>
<xsd:string>an Error</xsd:string>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

HTH,

Martin


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> I can not get this working without building my own SOAPResponder class
> and HttpRequest class, but I would assume that the framework provided
> by Cincom would work out of the box with TLS.

There really shouldn't be a problem here. SiouX supports NetHttpResponder over TLS out of the box. Try the following:

[>] There is a bug in reading Http POST messages in NetHttpResponder. The AR is created and fix will be provided for 7.10.1

Tamara

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Kogan, Tamara"<[hidden email]> wrote:
> > I can not get this working without building my own SOAPResponder class
> > and HttpRequest class, but I would assume that the framework provided
> > by Cincom would work out of the box with TLS.
>
> There really shouldn't be a problem here. SiouX supports NetHttpResponder over TLS out of the box. Try the following:
>
> [>] There is a bug in reading Http POST messages in NetHttpResponder. The AR is created and fix will be provided for 7.10.1

Fair enough, I'm not set up to test these things thoroughly anymore. I was mostly concerned about the implication that NetHttpResponder doesn't work with TLS at all.

Best regards,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc