Re: [nse] #212 - http.get_url makes plain text request for HTTPS urls

[Daniel Miller <bonsaiviking () gmail com>]

jah,

Thanks for the report. Very thorough! I added port.state = "open" to
get_url in r35251. I think this is enough to fix the issue. We can do an
audit later to determine if any other scripts or functions pass a
constructed port table without a state to comm.tryssl or shortport.ssl.

Dan

On Thu, Sep 17, 2015 at 5:43 PM, jah <jah () zadkiel plus com> wrote:

> List,
>
> Issue [#212] on github is reproduced below. The first HTTP request made by
> an NSE script which calls http.get_url with an https url is a plaintext
> request, instead of an encrypted one.
>
> I'm not sure of the best way to solve it.
>
> jah
>
> [#212]: https://github.com/nmap/nmap/issues/212
>
> - http.get_url parses the url to produce a port table: {service: "https",
> number: 443}
> - http.request is eventually called with the port table and this is passed
> to comm.tryssl
> - comm.tryssl passes the port table to comm.bestoption, which calls
> comm.is_ssl, which calls shortport.ssl
> - shortport.ssl calls shortport.port_or_service which returns false
> because both the port_checker and service_checker demand that port.state be
> either "open" or "open|filtered", but port.state is not set in this case
> - thus comm.tryssl uses opts.proto="tcp" instead of "ssl" when calling
> comm.opencon
>
> I can think of four fixes:-
>
> 1. shortport.includes, used by the checker functions, could return true if
> a nil value is being checked for inclusion in a set
> 2. the shortport checker functions could avoid testing port.state for
> inclusion in a set of states if port.state is not set (and return true when
> the other demands are met).
> 3. http.get_url could add port.state="open" after parsing its url argument.
> 4. http.request could set port.state
>
> Doing option 3 seems appropriate, but it doesn't help script writers using
> other http.lua functions such as get or head.  Option 1 seems like the
> right thing to do, except that it arguably violates the principle of least
> surprise.  Options 2 and 4 are probably not the appropriate places to solve
> this problem.
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/