Need additional kwarg option to prevent non-SSL redirects
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 54.3k
- Forks
- 10.4k
- Avg merge
- 16h 43m
- Merged PRs (30d)
- 3
Description
When a service erroneously send a redirect from an SSL URL to a non-SSL URL, there is a high possibility that secure data (such as passwords) get sent over plaintext without the application's knowledge. There should be an option to prevent such redirects and I am in favor of preventing such redirects by default, though it may break some existing client code.
Expected Result
Exception raised for requests.exceptions.SSLError
Actual Result
Redirection is automatically followed
Reproduction Steps
$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/C=IN/ST=TS/L=Hyderabad/O=Example.com/OU=R&D/CN=example.com"
$ echo -e "HTTP/1.1 302 Found\nLocation: http://google.com\n\n" | openssl s_server -key key.pem -cert cert.pem -accept 12345
$ python -c 'import requests; print requests.get("https://localhost:12345", verify=False).text'
System Information
$ python -c 'import requests; print requests.__version__'
2.8.1
$ python -V
Python 2.7.6
$ uname -a
Linux hdara1-wsl 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9 14:43:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the HTTPS-to-HTTP redirect behavior demonstrated by the openssl and Python reproduction, and trace where redirects are followed. Determine how the requested kwarg should govern that transition, then verify that the reproduction raises requests.exceptions.SSLError and that the chosen default behavior is documented and tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100