You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Alan Sunley <al...@gmail.com> on 2007/10/31 03:20:24 UTC
Enforcing transport level encryption
Greetings,
Is there a way to enforce transport level encryption with Rampart? I'm
experimenting with Policy example 01 using the TransportBinding and
HttpsToken assertions but I'm noticing that the soap messages are not
being encrypted when capturing them with TCPMon.
There was a similar post several months ago, without a specific
answer: http://www.mail-archive.com/rampart-dev@ws.apache.org/msg00379.html
Can I assume this is an error with the configuration and is not
expected behavior?
Regards,
Alan.
Re: Enforcing transport level encryption
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Alan,
We thought it is good to check what transport is used when Transport
binding
is used with Https Token. There is JIRA issue for this.
https://issues.apache.org/jira/browse/RAMPART-113
Would it simply be a matter of examining the endpoint string to see if
> it defines the https protocol?
IFAIK, checking the transport protocol used should simply work.
Regards,
Nandana
>
>
> Regards,
> Alan.
>
> On Nov 1, 2007 5:16 AM, Nandana Mihindukulasooriya
> <na...@gmail.com> wrote:
> > Hi Allan,
> >
> > It's using http. Is there no way enforce https, that is not to send
> > > the message at all if no https protocol is used?
> >
> >
> > I think your point is valid. I think Rampart should check the incoming
> > transport if we have a transport binding with https token. Can you
> > create a jira issue for this ?
> >
> > Regards,
> > Nandana
> >
>
Re: Enforcing transport level encryption
Posted by Alan Sunley <al...@gmail.com>.
Hi again,
Just as a quick follow-up question - this isn't strictly related to
Rampart, but I hope the security gurus here will be able to offer some
input - since Rampart doesn't enforce transport-level security, what
is a good way of enforcing transport-level security in the
application?
Would it simply be a matter of examining the endpoint string to see if
it defines the https protocol?
Regards,
Alan.
On Nov 1, 2007 5:16 AM, Nandana Mihindukulasooriya
<na...@gmail.com> wrote:
> Hi Allan,
>
> It's using http. Is there no way enforce https, that is not to send
> > the message at all if no https protocol is used?
>
>
> I think your point is valid. I think Rampart should check the incoming
> transport if we have a transport binding with https token. Can you
> create a jira issue for this ?
>
> Regards,
> Nandana
>
Re: Enforcing transport level encryption
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Allan,
It's using http. Is there no way enforce https, that is not to send
> the message at all if no https protocol is used?
I think your point is valid. I think Rampart should check the incoming
transport if we have a transport binding with https token. Can you
create a jira issue for this ?
Regards,
Nandana
Re: Enforcing transport level encryption
Posted by Alan Sunley <al...@gmail.com>.
Hi Nandana,
It's using http. Is there no way enforce https, that is not to send
the message at all if no https protocol is used? I can run a service
over https without specifying a HttpsToken in the policy so I'm
puzzled why there is a HttpsToken example with Rampart.
I have a situation where the client needs to connect to multiple
implementations of the same service wsdl. I won't have control over
these services but I need to ensure the confidentiality of certain
messages sent to these services. I'm trying to determine what the best
strategy is, whether to use transport level or message level security,
while keeping it as simple as possible - I don't want the client or
service sides to have to manage many keys/certificates.
By the way, thanks for your reply to my other question today.
Regards,
Alan.
On 10/31/07, Nandana Mihindukulasooriya <na...@gmail.com> wrote:
> HI Alan,
> can you post the what you capture with the TCPMon. I think in
> the earlier post you mentioned, the header says,
>
>
> POST /axis2/services/sample02 HTTP/1.1
>
>
> I think this gives us a clue. Here I think HTTP protocol is used not the
> HTTPS. Even though you have Transport binding with HTTP Token if
> you use the endpoint,
> http://xxxx/ axis2/services/xxx rather than
> https://xxxx/axis2/services/ xxx you are going through a unsecured
> channel, so soap messages can be read as plain text.
>
> So can you please check that you have not mistyped http for https.
>
> Regards,
> Nandana
>
>
> On 10/31/07, Alan Sunley <al...@gmail.com> wrote:
> >
> > Greetings,
> >
> > Is there a way to enforce transport level encryption with Rampart? I'm
> > experimenting with Policy example 01 using the TransportBinding and
> > HttpsToken assertions but I'm noticing that the soap messages are not
> > being encrypted when capturing them with TCPMon.
> >
> > There was a similar post several months ago, without a specific
> > answer:
> > http://www.mail-archive.com/rampart-dev@ws.apache.org/msg00379.html
> >
> > Can I assume this is an error with the configuration and is not
> > expected behavior?
> >
> > Regards,
> > Alan.
> >
>
Re: Enforcing transport level encryption
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
HI Alan,
can you post the what you capture with the TCPMon. I think in
the earlier post you mentioned, the header says,
POST /axis2/services/sample02 HTTP/1.1
I think this gives us a clue. Here I think HTTP protocol is used not the
HTTPS. Even though you have Transport binding with HTTP Token if
you use the endpoint,
http://xxxx/ axis2/services/xxx rather than
https://xxxx/axis2/services/ xxx you are going through a unsecured
channel, so soap messages can be read as plain text.
So can you please check that you have not mistyped http for https.
Regards,
Nandana
On 10/31/07, Alan Sunley <al...@gmail.com> wrote:
>
> Greetings,
>
> Is there a way to enforce transport level encryption with Rampart? I'm
> experimenting with Policy example 01 using the TransportBinding and
> HttpsToken assertions but I'm noticing that the soap messages are not
> being encrypted when capturing them with TCPMon.
>
> There was a similar post several months ago, without a specific
> answer:
> http://www.mail-archive.com/rampart-dev@ws.apache.org/msg00379.html
>
> Can I assume this is an error with the configuration and is not
> expected behavior?
>
> Regards,
> Alan.
>