[VW 7.6] does HTTPS work with proxy servers ?

Hello All,

Our application tries to connect to the Web using HTTPS and HTTP.
User sets a proxy information in the normal way.
And the HTTP traffic seem to work fine ( most of the time).

However the end  user reported the following trouble with the HTTPS

"The proxy servers reports null characters and unsupported method.
I have checked the connect acl, which is allowed on port 443. Squid
cache.log show this king of message :

2011/01/19 10:30:40| parseHttpRequest: Requestheader contains NULL
characters
2011/01/19 10:30:40| parseHttpRequest: Unsupported method ''
2011/01/19 10:30:40| clientReadRequest: FD 492 (192.168.17.220:1105)
Invalid Request

the access.log show

1295431093.651     15 192.168.17.220 TCP_DENIED/400 1612 NONE
error:unsupported-request-method - NONE/- text/html"

So I have few questions:

1.Does anyone know is there solution for this?
2. Can vw 7.6 use proxy for the HTTPS ?
3. There is a patch published for the VW 7.7 to address similar issue  
- can this patch be applied to the VW 7.6 ?

4. Can anyone here suggest a way to test the proxy servers. Do I need to
install one and which one ? or is there any type of public Proxy I can use ?


Any information is greatly appreciated.

Regards,

--Mark Pirogovsky


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

Contact Cincom Support and ask for their fix for this problem.

David Buck

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: Mark Pirogovsky <[hidden email]>
Sender: [hidden email]
Date: Wed, 19 Jan 2011 12:36:59
To: vwnc List<[hidden email]>
Subject: [vwnc] [VW 7.6]   does HTTPS work with proxy servers ?

Hello All,

Our application tries to connect to the Web using HTTPS and HTTP.
User sets a proxy information in the normal way.
And the HTTP traffic seem to work fine ( most of the time).

However the end  user reported the following trouble with the HTTPS

"The proxy servers reports null characters and unsupported method.
I have checked the connect acl, which is allowed on port 443. Squid
cache.log show this king of message :

2011/01/19 10:30:40| parseHttpRequest: Requestheader contains NULL
characters
2011/01/19 10:30:40| parseHttpRequest: Unsupported method ''
2011/01/19 10:30:40| clientReadRequest: FD 492 (192.168.17.220:1105)
Invalid Request

the access.log show

1295431093.651     15 192.168.17.220 TCP_DENIED/400 1612 NONE
error:unsupported-request-method - NONE/- text/html"

So I have few questions:

1.Does anyone know is there solution for this?
2. Can vw 7.6 use proxy for the HTTPS ?
3. There is a patch published for the VW 7.7 to address similar issue  
- can this patch be applied to the VW 7.6 ?

4. Can anyone here suggest a way to test the proxy servers. Do I need to
install one and which one ? or is there any type of public Proxy I can use ?


Any information is greatly appreciated.

Regards,

--Mark Pirogovsky


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

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

Proxy support for HTTPS was added in 7.7.1, so 7.6 wouldn't be able to get through a proxy using HTTPS. I don't know off the top of my head how difficult it would be to backport the changes.

Martin

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

Hi, I am having the below situation
I have exported an SSl certificate with CN = *.mySpace.com.
This is supposed to be the wild card for all hosts included in mySpace.com
Now, I am trying  HTTPS POST on 'interface.mySpace.com' and on validation of
the certificate chain, the below validationBlock excecution returns false
and i get an SSLBadCertificate


validationBlock

^validationBlock isNil
  ifTrue: [ [ :dnd | "Let's emulate web browser validation as default"
     hostName = (dnd at: 'CN') ] ]
  ifFalse: [ validationBlock ]


(here hostname='interface.mySpace.com and
dnd at:CN  = *.mySpace.com)

Can anyone suggest some solution?

Thanks in advance,

Simon

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

This is fixed in the upcoming 7.8 release, we will allow wildcard certificates by default. In the meantime you'll have to override the default validation block with your own, more permissive one. Unfortunately there isn't an easy way to do it globally in previous releases. You'll either have to set it explicitly for specific servers or you'll have to modify the default block in the NetClient code.

HTH,

Martin

"Simon Peter"<[hidden email]> wrote:

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

Thanks, Martin. This is good news, we keep an override, but this would be better.

Sent from my iPhone

On 28 Jan 2011, at 10:37, "[hidden email]" <[hidden email]> wrote:

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

Martin,

While we're on the subject (pun not intended), could you tell me if the
following problem had also been addressed?

When making an unsecured request via http that immediately results in a
302 to https address, the validation block isn't preserved on the new
connection, so subject validation fails in the following snippet,

c := (HttpClient new)
        validationBlock: [:dnd | dnd CN match: self hostName];
        yourself.
c executeRequest: (HttpRequest get: 'http://demo.deepcovelabs.com')

The problem could be narrowed down to the below method,

NetProtocolInterpreter>>useSecureConnection
        self loadSecureConnection.
        connection := self sslConnectionClass new.

C:\Users\Administrator>curl -i http://demo.deepcovelabs.com
HTTP/1.0 302 Found
Location: https://demo.deepcovelabs.com/online
Server: BigIP
Connection: Keep-Alive
Content-Length: 0

Thanks,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov, DeepCove Labs
Sent: Friday, January 28, 2011 10:40 AM
To: [hidden email]
Cc: vwnc List
Subject: Re: [vwnc] [VW:7.6]SSL BadCertificate

Thanks, Martin. This is good news, we keep an override, but this would
be better.

Sent from my iPhone

On 28 Jan 2011, at 10:37, "[hidden email]" <[hidden email]>
wrote:

> This is fixed in the upcoming 7.8 release, we will allow wildcard
certificates by default. In the meantime you'll have to override the
default validation block with your own, more permissive one.
Unfortunately there isn't an easy way to do it globally in previous
releases. You'll either have to set it explicitly for specific servers
or you'll have to modify the default block in the NetClient code.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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

I'm not aware of there being an issue with redirects, so my first guess would have been that if there was an issue before it would still be there. But when I try the following I get a response (from recent 7.8 build):

c := (HttpClient new)
        useSecureConnection;
        validationBlock: [:dnd | dnd CN match: 'demo.deepcovelabs.com'];
        yourself.
c executeRequest: (HttpRequest get: 'http://demo.deepcovelabs.com')

Note that I have to tell the client to useSecureConnection, otherwise it won't let me set the validationBlock:. So it seems that we might have fixed this as a side-effect of other changes. Does that look OK to you ?

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Martin,

What happens when you simply do the following?

HttpClient get: 'http://demo.deepcovelabs.com'

Surely one shouldn't need to explicitly use #useSecureConnection when
any URL could end up redirecting from non-secure to secure and vice
versa? I should be able to set a validation block on any client and know
that it will be preserved during http-https redirect or any number of
transitions in fact.

Regards,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, January 28, 2011 4:01 PM
To: Boris Popov, DeepCove Labs
Cc: vwnc List
Subject: RE: [vwnc] [VW:7.6]SSL BadCertificate

I'm not aware of there being an issue with redirects, so my first guess
would have been that if there was an issue before it would still be
there. But when I try the following I get a response (from recent 7.8
build):

c := (HttpClient new)
        useSecureConnection;
        validationBlock: [:dnd | dnd CN match: 'demo.deepcovelabs.com'];
        yourself.
c executeRequest: (HttpRequest get: 'http://demo.deepcovelabs.com')

Note that I have to tell the client to useSecureConnection, otherwise it
won't let me set the validationBlock:. So it seems that we might have
fixed this as a side-effect of other changes. Does that look OK to you ?

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> What happens when you simply do the following?
>
> HttpClient get: 'http://demo.deepcovelabs.com'

It works but that's likely because it picks up the (now more permissive) default validation block. Which makes me wonder if what I observed also isn't just a side-effect of the new default, rather than us preserving the validation context correctly. I'll have to look into that.

> Surely one shouldn't need to explicitly use #useSecureConnection when
> any URL could end up redirecting from non-secure to secure and vice
> versa? I should be able to set a validation block on any client and know
> that it will be preserved during http-https redirect or any number of
> transitions in fact.

There are two things at play here:

1) preserving the validation context in redirects: that sounds desirable, although I'll have to ponder some more complex scenarios with cross-site redirects to be sure

2) configuring the security parameters of the client (regardless of redirects): We can certainly hide the useSecureConnection send inside the setup calls like validationBlock:, but it doesn't work that way right now. At the moment I don't know if this is how it used to work or if this is something we've just changed.

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

Martin,

Re: new behavior, it could very well be that it works now because new
default in 7.8 accepts wildcards.

Re: validation block, from where I'm standing, I'd like to choose a
validation policy on a client (not connection) for the duration of the
whole HTTP request even if it includes multiple redirects/connections,
so being able to set it on a client without explicitly using
#useSecureConnection and having it preserved through (possible) multiple
new connections would be desirable.

Thanks,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, January 28, 2011 4:24 PM
To: Boris Popov, DeepCove Labs
Cc: vwnc List
Subject: RE: [vwnc] [VW:7.6]SSL BadCertificate

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> What happens when you simply do the following?
>
> HttpClient get: 'http://demo.deepcovelabs.com'

It works but that's likely because it picks up the (now more permissive)
default validation block. Which makes me wonder if what I observed also
isn't just a side-effect of the new default, rather than us preserving
the validation context correctly. I'll have to look into that.

> Surely one shouldn't need to explicitly use #useSecureConnection when
> any URL could end up redirecting from non-secure to secure and vice
> versa? I should be able to set a validation block on any client and
> know that it will be preserved during http-https redirect or any
> number of transitions in fact.

There are two things at play here:

1) preserving the validation context in redirects: that sounds
desirable, although I'll have to ponder some more complex scenarios with
cross-site redirects to be sure

2) configuring the security parameters of the client (regardless of
redirects): We can certainly hide the useSecureConnection send inside
the setup calls like validationBlock:, but it doesn't work that way
right now. At the moment I don't know if this is how it used to work or
if this is something we've just changed.

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

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> Re: validation block, from where I'm standing, I'd like to choose a
> validation policy on a client (not connection) for the duration of the
> whole HTTP request even if it includes multiple redirects/connections,
> so being able to set it on a client without explicitly using
> #useSecureConnection and having it preserved through (possible) multiple
> new connections would be desirable.

Of course, that's reasonably obvious and easy requirement. I'm thinking more about the more complex scenarios. E.g. where first link redirects to https on domaing A which then redirects to https on domain B. Is it adequate to handle this with single validationBlock ? Especially since the block doesn't have an easy indication of which part of the redirection setup it's dealing with at any given moment ? Or is this setup too artificial and we don't need to worry about it ?

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

I would tend to say that it is artificial, because most of the time
client would be invoked with a single intent and validation policy. If
one was concerned with redirect security, client could handle 302s and
make decisions in-flight.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Monday, January 31, 2011 11:49 AM
To: Boris Popov, DeepCove Labs
Cc: vwnc List
Subject: RE: [vwnc] [VW:7.6]SSL BadCertificate

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> Re: validation block, from where I'm standing, I'd like to choose a
> validation policy on a client (not connection) for the duration of the

> whole HTTP request even if it includes multiple redirects/connections,

> so being able to set it on a client without explicitly using
> #useSecureConnection and having it preserved through (possible)
> multiple new connections would be desirable.

Of course, that's reasonably obvious and easy requirement. I'm thinking
more about the more complex scenarios. E.g. where first link redirects
to https on domaing A which then redirects to https on domain B. Is it
adequate to handle this with single validationBlock ? Especially since
the block doesn't have an easy indication of which part of the
redirection setup it's dealing with at any given moment ? Or is this
setup too artificial and we don't need to worry about it ?

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