Ability to run both SSL and non SSL attacks from one YML file

[anshumanbh]

Hello again,

Another feature request:

Right now, the YML files take in a value for ssl. Can we also add another value here both so that instead of creating two separate files for ssl: true and ssl: false, we can just provide both and it should automatically try to run both?

Cheers!

[ztgrace]

Hey @anshumanbh,

I was just thinking about a similar feature where you could specify --ssl as an argument to force it to SSL.

For your use case, are you seeing services that in one version have SSL and in another version don't have it? What I want to be careful about is adding extra requests and unnecessarily slowing down scans.

If I were to implement the both feature, I'd likely try the SSL version first, then the non-SSL. That way it "prefers" the encrypted connection and then I could catch the requests.exceptions.SSLError as a way to handle the non-SSL call.

[anshumanbh]

yeah, I encountered two open consoles yesterday. One was over http and the other one was over https (with an invalid SSL cert configured that was throwing errors).

Typing something like ./changeme --protocols http --portoverride $HOST:$PORT didn't work for both the hosts even though the $PORT was 80 for the first one and 443 for the second one.

When the ssl value in the YML was false, the above command worked for the http host. And, when the ssl value in the YML was true, it worked for the https host. So, I had to create two YML files with ssl value true and ssl value false.

And I am sure there are plenty of usecases like these where we are possibly missing out because of the ssl value.

I like your idea to start with ssl and then deal with non ssl if an error instead of having "both". Whatever makes sense to you really.

[ztgrace]

I guess I'd like to keep the cred files as close to the "default" install as possible and introduce an option to have this behavior.

[anshumanbh]

sounds good! thanks and appreciate it

[ztgrace]

Implemented in v1.1.