verify=False and requests.packages.urllib3.disable_warnings()

[invisiblethreat]

As of 1.9 of urllib3, the following warning appears once per invocation:

/usr/local/lib/python2.7/site-packages/requests-2.4.0-py2.7.egg/requests/packages/urllib3/connectionpool.py:730: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html (This warning will only appear once by default.)
  InsecureRequestWarning)

When using verify=False would it be useful to also set requests.packages.urllib3.disable_warnings()?

I understand that this is a design decision that not everyone might agree with. :)

[thexder1]

The way that I see it, if an application is using a url set by a user then the user should be provided with an option to disable verify but in every situation I can think of they should get the warning. If as a developer and you know for what ever reason you are connecting to a url that is not expected to have a valid certificate (internal services that you will not pay for a certificate for, test etc) then you should have the option to disable the warnings along with disabling the verification.

At the same time I do not think it will be common to have a situation where you would want to disable the warnings globally in one go as that makes it too easy to open up security issues that are silently ignored.

[101t]

requests.packages.urllib3.disable_warnings() yes it is work

[SamJoan]

Hi there

Is requests.packages.urllib3.disable_warnings() not working anymore? it used to silence the warnings for me. Here is where I am calling the disable warnings function, and here is an example backtrace where the warning function is called:

[+] Accepted redirect to https://drupal.org/
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(791)_validate_conn()
-> warnings.warn((
(Pdb) bt
  /root/droopescan/droopescan(5)()
-> droopescan.main()
  /root/droopescan/dscan/droopescan.py(55)main()
-> ds.run()
  /usr/local/lib/python2.7/dist-packages/cement/core/foundation.py(764)run()
-> self.controller._dispatch()
  /usr/local/lib/python2.7/dist-packages/cement/core/controller.py(466)_dispatch()
-> return func()
  /usr/local/lib/python2.7/dist-packages/cement/core/controller.py(472)_dispatch()
-> return func()
  /root/droopescan/dscan/plugins/internal/scan.py(114)default()
-> follow_redirects)
  /root/droopescan/dscan/plugins/internal/scan.py(230)_process_cms_identify()
-> if inst.cms_identify(url, opts['timeout'], self._generate_headers(host_header)) == True:
  /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(910)cms_identify()
-> headers)
  /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(827)enumerate_file_hash()
-> r = self.session.get(url + file_url, timeout=timeout, headers=headers)
  /usr/lib/python2.7/dist-packages/requests/sessions.py(480)get()
-> return self.request('GET', url, **kwargs)
  /usr/lib/python2.7/dist-packages/requests/sessions.py(468)request()
-> resp = self.send(prep, **send_kwargs)
  /usr/lib/python2.7/dist-packages/requests/sessions.py(576)send()
-> r = adapter.send(request, **kwargs)
  /usr/lib/python2.7/dist-packages/requests/adapters.py(376)send()
-> timeout=timeout
  /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(559)urlopen()
-> body=body, headers=headers)
  /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(345)_make_request()
-> self._validate_conn(conn)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(791)_validate_conn()
-> warnings.warn((

The following is the output of pip freeze, I am using debian testing:

argparse==1.2.1
beautifulsoup4==4.4.1
cement==2.6.2
chardet==2.3.0
colorama==0.3.3
coverage==4.0.3
cryptography==1.2.1
distlib==0.2.1
-e git+git@github.com:droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
enum34==1.1.2
funcsigs==0.4
futures==3.0.4
html5lib==0.999
httplib2==0.9.1
idna==2.0
ipaddress==1.0.16
lxml==3.5.0
mercurial==3.5.2
mock==1.3.0
ndg-httpsclient==0.4.0
nose==1.3.7
pbr==1.8.1
pyOpenSSL==0.15.1
pyasn1==0.1.9
pycurl==7.21.5
pystache==0.5.4
python-apt==1.1.0b1
python-debian==0.1.27
python-debianbts==2.6.0
reportbug==6.6.6
requests==2.9.1
responses==0.3.0
retrying==1.3.3
six==1.10.0
urllib3==1.13.1
wheel==0.26.0
wsgiref==0.1.2

Thanks, Pedro

[Lukasa]

disable_warnings doesn't prevent the warning function from being called, it just suppresses the output. You may encounter problems if some other bit of code enables all warnings.

[SamJoan]

Hi @Lukasa,

I put the breakpoint after the if. In the end I stopped using debian testing as I came across too many issues, and this may very well be one of them. I would just ignore my comment, I am not sure what happened but it is likely not something that will affect a lot of people.

Thanks! Pedr

[Lukasa]

Yeah, so if you were using a package from debian it's possible their unvendoring logic broke something here.

[j0hnsmith]

Wanting to make an insecure request by specifying verify=False and not see a warning for that request, without interfering with warnings for any other requests made elsewhere seems perfectly reasonable.

from requests.packages.urllib3.exceptions import InsecureRequestWarning

...
with warnings.catch_warnings():
    warnings.filterwarnings("ignore", category=InsecureRequestWarning)
    resp = requests.get(url, verify=False)  # InsecureRequestWarning suppressed for this request

resp = requests.get(url, verify=False)  # InsecureRequestWarning not suppressed for this request
...