NetWebmethod: Only Serve if Secure TLS

[Poul]

Hello,
i am trying to confirm something as my web-service behaves different than i expect.

i have setup a self signed certificate (The server is Configured to USE TLS)
a regular web page works as expected from a browser.
I  can use both Basic or Digest HTTP authentication for a webservice which appears to be working fine.

as an example,
for an  employees NetWebservice Method i have  set the security to "Only Serve if Secure TLS"

a Client that does a "GET for https://myserverapi/v1/employees" appears to work fine.

but a "GET for http://myserverapi/v1/employees" also works, i was expecting nothing to return or an error.

How can i tell if the connection is truly thru TLS or not?
The SSL method seems to indicate that its TRUE.

If i turn off the "Only Serve if Secure TLS" for the method, the SSL flag still indicates true
Does the server setting take precedence over the http(s) protocol in the request?

I'd like to test and enforce that https:// has been specified by the client explicitly for any web-service call.

is this something i should be concerned over or is this expected behavior.

TIA
poul

[Bruce]

Hi Poul,

>> How can i tell if the connection is truly thru TLS or not?

p_web.RequestData.WebServer.SSL is set to either true or false.

>> Does the server setting take precedence over the http(s) protocol in the request?

no, but there may be a "middle step" which is fooling you - it all depends on how your server is setup.
One typical way to set up the server is to have "2 server objects" in WebServer procedure.
The one listens on port 80, and is set to "Always redirect to Secure Site".
So then the user comes in on http, but gets a redirect back, then asks again on https, and hence gets the answer.

cheers
Bruce

[Poul]

no only one object.

so is it correct to say if i have only one webserver object and its set to use TLS
that the setting in the netwebserver  "only serve if Secure TLS" has no meaningful impact?
(perhaps it might have more utility  in multiple port model?)
i see it  generates

Code: [Select]

   
    If p_web.RequestData.WebServer.SSL = 0
      p_web.CloseConnection()
      Return ''
    End
but p_web.RequestData.WebServer.SSL is always true regardless if the client specifies http or https in the request
in other words its always TLS  or nothing when doing requests.

OIC !, its an artifact of how my testprogram - NetwebClient communicates!  it was based on your demo
Even if my server does a  p_web.SetSessionLoggedIn(0) after a webservicemethod (keeping things RESTful) it still 'remembers' and uses how the initial connection is made
regardless of the how the subsequent request is made.
So when i change the request to http and test - it still works, if i close the client screen and try again with just http  - it complains as expected.

Resolution:
The server is working but my testclient is messing with me.
dunno if its best but for my REST TEST program,  i added a net.init() in my webclient in pagerecieve and its all good.
i can do repeated tests and get the behaviour i expected.

thanks
poul

[Bruce]

Hi Poul,

>>  it still 'remembers' and uses how the initial connection is made regardless of the how the subsequent request is made.

Interesting. I might be inclined to treat this as a bug in the client. It's opening the connection for the first request, then keeping it open. The second request has the same host name (ie www.poul.com) - only the _protocol_ is different. But (the bug) is that it only compares _host_ not _protocol_ when deciding if the currently-open-connection is still ok.

>>  is it correct to say if i have only one webserver object and its set to use TLS that the setting in the netwebserver  "only serve if Secure TLS" has no meaningful impact?

yes. (although it never hurts to have it on anyway.)

Cheers
Bruce

[Poul]

"inclined to treat this as a bug in the client"

perhaps, i wasn't sure if there was a property/method  to clear (or that i had inadvertently set)  before sending the request, but i was more
concerned with the server rather than the client. Init seemed to work.

I wasn't sure if it was by design/accident or on purpose,  browsers when using  BASIC / DIGEST http authentication will cache
things and appear to do something similar (you have to close the browser to re-enter credentials) ,  so maybe its useful to have the
client have the ability to force TLS regardless of the formatted protocol request once the initial connection is made,
but I feel its wrong to be the default behaviour. (nor really required in the class itself), as it flys in the face of my stateless pursuit.

poul

[Bruce]

Hi Poul,

I've done some digging, and it turns out my post above was right in theory, but complete nonsense.
Firstly (and perhaps most obviously) changing from HTTP to HTTPS changes the default port being connected on, and hence the keep-alive test would automatically fail anyway.

Apart from that I found some issues in the keep-alive code which meant the netwebclient _always_ terminated the connection anyway, so it wasn't going to work anyway. (I've fixed this for the 9.20 build.)

So back to your first question - and this is hard to test further without the real URL (which you can send me if you like) but if you are making an HTTP connection to the server then there has to be _something_ which is either trapping those requests and redirecting them (most likely) or some other server running on port 80.

Cheers
Bruce

[Poul]

Hi bruce,

i am quite confident there is only my NT apps and nothing else using both the default and my test ports.
i was testing with 2 servers and 3 client - (local, LAN and WAN scenarios).
and i have never used more than one web handler. Some of my testing would have included some explicit ports as well, ie 8080 etc ie:

Code: [Select]

would https://test:88/testthis  followed by a http://test:88/testthis  request be detected as a different port?
my initial concern was that it was the server, I am more comfortable with it being a confused client. (even if its mine)

But i am also seeing something strange with gzip which i cannot quite explain,  what i will do is as time permits is build a
sample server and client from scratch with latest updates  and see if i can "capture" some of this for you in a bottle,
I will start a new thread if i find something to share.

thanks
poul