SSLError: EOF occurred in violation of protocol

I am behind a proxy at work and in order for my requests to be routed (even internally) I have to connect to a proxy. I have tried doing so in multiple different ways in order to get my script to function. 

I can run things such as the `easy_install` command line tool if I set the `http_proxy` and `https_proxy` environment variables to: `protocol://my_username:my_password@proxy_fqdn:proxy_port` (`protocol` = http or https). It appears that Requests does not look for this information however so I am left to use an HTTPProxyAuth object.

Relevant information to my setup/environment
- Python 2.6
- Requests 1.2.3
- Red Hat Enterprise Linux 6.4
- My full username has a backslash (\) in it since all employees use Active Record credentials (ie: domain\username) - the domain only consists of alphabetic characters
- My password has symbols in it (ie: !@#$%^&\* etc.)

Stack trace

```
Traceback (most recent call last):
  File "mpss.py", line omitted, in <module>
    print main(args)
  File "mpss.py", line omitted, in main
    content = sesh.get(URL_MPSS_BUILDS, proxies=PROXIES, auth=auth).content
  File "/usr/lib/python2.6/site-packages/requests-1.2.3-py2.6.egg/requests/sessions.py", line 347, in get
    return self.request('GET', url, **kwargs)
  File "/usr/lib/python2.6/site-packages/requests-1.2.3-py2.6.egg/requests/sessions.py", line 335, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.6/site-packages/requests-1.2.3-py2.6.egg/requests/sessions.py", line 438, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.6/site-packages/requests-1.2.3-py2.6.egg/requests/adapters.py", line 331, in send
    raise SSLError(e)
requests.exceptions.SSLError: [Errno 8] _ssl.c:490: EOF occurred in violation of protocol
```

Source

```
from requests import Session
from requests.auth import HTTPProxyAuth

URL_MPSS_BUILDS = 'https://sub.domain.employer.com/builds/mpss/'

PROXIES = {
    'http':  'http://proxy.campus.employer.com:911',
    'https': 'https://proxy.campus.employer.com:911'
}

sesh = Session()
auth = HTTPProxyAuth(username, password)
content = sesh.get(URL_MPSS_BUILDS, proxies=PROXIES, auth=auth).content
```

Please note that my actual code looks a lot nicer - I have extracted the relevant lines as needed to reproduce this bug.

Is there anything I am doing wrong? I have also tried the following variations to find a fix:
- Remove protocol from value portion of the `PROXIES` dictionary --> Causes a KeyError similar to #997
- Tried formatting the PROXIES values with user:pass@fqdn:port but that didn't work - didn't expect it to either

Proxy preferences in RHEL 6.4 - this is the system I am running this script on as well as where I got the initial proxy FQDNs from. I checked the laptop that was issued to me by my employer and it has the same settings as well.

![proxy prefs](https://f.cloud.github.com/assets/819571/770765/53a5e8cc-e8d4-11e2-9c25-d3344ecabdc4.png)


Try to use `http://` in both proxy urls.
Please be aware, that support fpr https over proxies is in fact broken. However, depending on your proxy software it may work nevertheless, although the data isn't encrypted on the way between your proxy and you and only gets encrypted by the proxy. You have to try it yourself and decide, whether this restriction doesn't prevent you from using it.

``` py
PROXIES = {
    'http':  'http://proxy.campus.employer.com:911',
    'https': 'http://proxy.campus.employer.com:911'
}
```


To elaborate on what @t-8ch has just said, this is a known bug in Requests and has been around for some time (see #1359). Until we manage to get proper HTTPS proxying support in urllib3 there is very little we can do about it. Try following @t-8ch's suggestions for the moment.


Forgot to mention in my list that I have already tried that...

```
<HTML><HEAD>
<TITLE>Request Error</TITLE>
</HEAD>
<BODY>
<FONT face="Helvetica">
<big><strong></strong></big><BR>
</FONT>
<blockquote>
<TABLE border=0 cellPadding=1 width="80%">
<TR><TD>
<FONT face="Helvetica">
<big>Request Error (invalid_request)</big>
<BR>
<BR>
</FONT>
</TD></TR>
<TR><TD>
<FONT face="Helvetica">
Your request could not be processed. Request could not be handled
</FONT>
</TD></TR>
<TR><TD>
<FONT face="Helvetica">
This could be caused by a misconfiguration, or possibly a malformed request.
</FONT>
</TD></TR>
<TR><TD>
<FONT face="Helvetica" SIZE=2>
<BR>
For assistance, contact your network support team.
</FONT>
</TD></TR>
</TABLE>
</blockquote>
</FONT>
</BODY></HTML>
```


I know this isn't exactly helpful but thank you for such an excellent issue report. One thing I'd ask to see, out of some level of curiosity, is which version of openssl you're running. While @t-8ch and @lukasa are 100% correct, I wonder of this isn't an SSL issue being masked by proxies.


As a member of a debug team of a broad software stack, I understand the 
agony of trying to find the root cause of bugs from customers that don't 
submit detailed bug reports. It took a good chunk of time out of my 
lunch break to prepare it, but I just thought that making it easier on 
you guys would speed things along. I really appreciate the requests 
library and how easy it makes Python web interactions. I'd like to thank 
you guys for all the work you do to keep this open source project active 
and going in the right direction. If I do find a work around, I'll be 
sure to post it here so others can find it.

Feel free to close this if you deem it necessary.

On 7/9/2013 7:36 PM, Ian Cordasco wrote:

> I know this isn't exactly helpful but thank you for such an excellent 
> issue report. One thing I'd ask to see, out of some level of 
> curiosity, is which version of openssl you're running. While @t-8ch 
> https://github.com/t-8ch and @lukasa https://github.com/lukasa are 
> 100% correct, I wonder of this isn't an SSL issue being masked by proxies.
> 
> —
> Reply to this email directly or view it on GitHub 
> https://github.com/kennethreitz/requests/issues/1449#issuecomment-20718442.


It's perfectly possible this is an SSL issue, SSL negotiation problems tend to show similar errors. I need to spend some time looking into the proxy stuff in Requests, and get clear in my head what we can and can't do. In the meantime, @kylestev, it would be worth trying to grab tcpdump from the connection: it's possible the SSL handshake isn't completing.


I can do this tomorrow. I was out of office today and my dev machine (w/
rhel) is at the office. Will update tomorrow with tcpdump
On Jul 9, 2013 11:18 PM, "Cory Benfield" notifications@github.com wrote:

> It's perfectly possible this is an SSL issue, SSL negotiation problems
> tend to show similar errors. I need to spend some time looking into the
> proxy stuff in Requests, and get clear in my head what we can and can't do.
> In the meantime, @kylestev https://github.com/kylestev, it would be
> worth trying to grab tcpdump from the connection: it's possible the SSL
> handshake isn't completing.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1449#issuecomment-20723581
> .


@kylestev any update? 


Closed due to inactivity.