简体   繁体   English

当使用通过conda安装的R时,install.packages不能与代理一起使用

[英]install.packages doesn't work with proxy when using R installed with conda

I am working on a Linux server RHEL6 and I installed anaconda. 我正在Linux服务器RHEL6上工作,并且安装了anaconda。 I have the following setup 我有以下设置

 conda-env version : 4.3.13
 conda-build version : 2.1.4
 python version : 2.7.13.final.0
 rpy2 : 2.8.5

I installed rpy2 to use R in python 我安装了rpy2以在python中使用R

> R.home()
[1] "/anaconda2/envs/py27CCA/lib/R"
> R.version 
version.string R version 3.3.2 (2016-10-31) 

I setup my proxy in the following way: 我通过以下方式设置代理:

> Sys.getenv("https_proxy")
[1] "https://login:pwd@xxx.net:8080/"

But downloading R packages doesn't work 但是下载R包不起作用

> options(internet.info = 0)
> install.packages("httr")

* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
....
Warning: unable to access index for repository https://stat.ethz.ch/CRAN/src/contrib:
  cannot download all files
Warning message:
package 'httr' is not available (for R version 3.3.2)

But If I installed the same standalone R version with the exact same proxy setup it works without any issue 但是,如果我使用完全相同的代理设置安装了相同的独立R版本,则可以正常工作

> R.version 
version.string R version 3.3.2 (2016-10-31) 
> install.packages("httr")
...
** testing if installed package can be loaded
* DONE (httr)
Making 'packages.html' ... done
...

What is creating this issue ? 是什么造成了这个问题? I check the openssl version and I have the same version in the 2 environments! 我检查了openssl版本,并且在2个环境中都具有相同的版本! This link explain the possible reason of such proxy issue link stackoverflow discussion . 该链接说明了此类代理问题链接stackoverflow讨论的可能原因。

I have the same issue and error messages if I do it inside python 如果我在python中执行此操作,则会遇到相同的问题和错误消息

>>> from rpy2.robjects.packages import importr
>>> utils = importr('utils')
>>> utils.install_packages('httr')

TL;DR: TL; DR:

Instead of setting https_proxy to...: 而不是将https_proxy设置为...:

https://login:pwd@xxx.net:8080/

...try setting it to: ...尝试将其设置为:

http://login:pwd@xxx.net:8080/

Also, by doing this, if someone sniffs packets of the initial connection you make with the proxy server, you will be leaking your credentials. 同样,通过这样做,如果有人嗅探您与代理服务器建立的初始连接的数据包,则您将泄漏您的凭据。 Read further to know more. 进一步阅读以了解更多信息。


IMO, this question has nothing to do with Conda. IMO,这个问题与Conda无关。 This is a very common mistake which I find quite prevalent on the internet. 这是一个非常常见的错误,我发现它在互联网上非常普遍。

The reason why this happens, is because of the confusion lying around the term "HTTPS Proxy". 发生这种情况的原因是因为围绕“ HTTPS代理”一词的困惑。

IIUC, here is what the two environment variables mean: IIUC,这是两个环境变量的含义:

http_proxy|HTTP_PROXY: The proxy server that you wish to use, for all your HTTP requests to the outside world. http_proxy | HTTP_PROXY:您希望使用的代理服务器,用于您对外界的所有HTTP请求。

https_proxy|HTTPS_PROXY: The proxy server that you wish to use, for all your HTTPS requests to the outside world. https_proxy | HTTPS_PROXY:您希望使用的代理服务器,用于您对外界的所有HTTPS请求。

http(s?)://proxy.mydomain.com:3128
 ^^^^^          ^^^^^         ^^^^   
   |              |             |    
scheme    proxy domain/IP   proxy port

Now, ideally, the scheme specified in the value for these environment variables determines the protocol over which the client ought to connect to the proxy server. 现在,理想情况下,在这些环境变量的值中指定的方案确定了客户端应通过其连接到代理服务器的协议。


Let's look at definition of an HTTPS proxy. 让我们看一下HTTPS代理的定义。 Stealing from the man page for curl >= v7.53 : 从手册页中窃取curl >= v7.53

An HTTPS proxy receives all transactions over an SSL/TLS connection.
Once a secure connection with the proxy is established, the user agent
uses the proxy as usual, including sending CONNECT requests to instruct
the proxy to establish a [usually secure] TCP tunnel with an origin
server. HTTPS proxies protect nearly all aspects of user-proxy
communications as opposed to HTTP proxies that receive all requests
(including CONNECT requests) in vulnerable clear text.

With HTTPS proxies, it is possible to have two concurrent _nested_
SSL/TLS sessions: the "outer" one between the user agent and the proxy
and the "inner" one between the user agent and the origin server
(through the proxy). This change adds supports for such nested sessions
as well.

Let's try and see with examples (curl >= v7.53) : 让我们尝试使用示例(curl >= v7.53)

Here, I'll use a proxy which does not support client-proxy connection over SSL/TLS. 在这里,我将使用不支持通过SSL / TLS进行客户端代理连接的代理。

Make sure no proxy environment variables are set beforehand: 确保没有预先设置代理环境变量:

((curl-7_53_1))$ env | grep -i proxy
((curl-7_53_1))$ 

env: http_proxy, outer_scheme: http, inner_scheme: http env:http_proxy,external_scheme:http,inner_scheme:http

((curl-7_53_1))$ http_proxy="http://proxy.mydomain.com:3128" ./src/curl -s -vvv http://stackoverflow.com -o /dev/null
* Rebuilt URL to: http://stackoverflow.com/
*   Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
> GET http://stackoverflow.com/ HTTP/1.1
> Host: stackoverflow.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< X-Frame-Options: SAMEORIGIN
< X-Request-Guid: 539728ee-a91d-4964-bc7e-1d21d91a6f1d
< Content-Length: 228257
< Accept-Ranges: bytes
< Date: Thu, 16 Mar 2017 05:19:31 GMT
< X-Served-By: cache-jfk8137-JFK
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1489641571.098286,VS0,VE7
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=b2e2dcb8-c5ff-21d9-5712-a0e012573aa6; domain=.stackoverflow.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
< X-Cache: MISS from proxy.mydomain.com
< X-Cache-Lookup: MISS from proxy.mydomain.com:3128
< Via: 1.1 varnish, 1.0 proxy.mydomain.com (squid)
* HTTP/1.0 connection set to keep alive!
< Connection: keep-alive
<
{ [2816 bytes data]
* Connection #0 to host proxy.mydomain.com left intact

env: http_proxy, outer_scheme: https, inner_scheme: http env:http_proxy,external_scheme:https,inner_scheme:http

((curl-7_53_1))$ http_proxy="https://proxy.mydomain.com:3128" ./src/curl -s -vvv http://stackoverflow.com -o /dev/null
* Rebuilt URL to: http://stackoverflow.com/
*   Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0

env: https_proxy, outer_scheme: http, inner_scheme: https env:https_proxy,external_scheme:http,inner_scheme:https

((curl-7_53_1))$ https_proxy="http://proxy.mydomain.com:3128" ./src/curl -s -vvv https://stackoverflow.com -o /dev/null
* Rebuilt URL to: https://stackoverflow.com/
*   Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
* Establish HTTP proxy tunnel to stackoverflow.com:443
> CONNECT stackoverflow.com:443 HTTP/1.1
> Host: stackoverflow.com:443
> User-Agent: curl/7.53.1-DEV
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection established
<
* Proxy replied OK to CONNECT request
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3044 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=NY; L=New York; O=Stack Exchange, Inc.; CN=*.stackexchange.com
*  start date: May 21 00:00:00 2016 GMT
*  expire date: Aug 14 12:00:00 2019 GMT
*  subjectAltName: host "stackoverflow.com" matched cert's "stackoverflow.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
} [5 bytes data]
> GET / HTTP/1.1
> Host: stackoverflow.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< X-Frame-Options: SAMEORIGIN
< X-Request-Guid: 96f8fe3c-058b-479e-8ef2-db6d09f485d3
< Content-Length: 226580
< Accept-Ranges: bytes
< Date: Thu, 16 Mar 2017 05:20:39 GMT
< Via: 1.1 varnish
< Connection: keep-alive
< X-Served-By: cache-jfk8135-JFK
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1489641639.425108,VS0,VE9
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=f1a401f1-f1a0-5f09-66ca-9a792543ee82; domain=.stackoverflow.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
<
{ [2181 bytes data]
* Connection #0 to host proxy.mydomain.com left intact

env: https_proxy, outer_scheme: https, inner_scheme: https env:https_proxy,external_scheme:https,inner_scheme:https

((curl-7_53_1))$ https_proxy="https://proxy.mydomain.com:3128" ./src/curl -s -vvv https://stackoverflow.com -o /dev/null
* Rebuilt URL to: https://stackoverflow.com/
*   Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0

Now, I'll show the same outputs for a proxy which supports connection over SSL/TLS. 现在,我将显示支持通过SSL / TLS进行连接的代理的相同输出。 To run a local https proxy, I have installed squid version 4.0.17. 要运行本地https代理,我已经安装了鱿鱼版本4.0.17。 I have pointed proxy.mydomain.com to localhost by overriding it in /etc/hosts . 我通过在/etc/hosts覆盖proxy.mydomain.com使其指向localhost。 And the relevant squid config line is: 和相关的鱿鱼配置行是:

https_port 3127 cert=/etc/squid/ssl_cert/myCA.pem

Please note that I am not using any explicitly specified (complicated?) modes right now (sslbump/intercept/accel/tproxy) 请注意,我现在不使用任何明确指定的(复杂的?)模式(sslbump / intercept / accel / tproxy)

I have added the certificate to the trust store too: 我也将证书添加到了信任存储中:

sudo cp /etc/squid/ssl_cert/myCA.pem /etc/pki/ca-trust/source/anchors/mySquidCA.pem
sudo update-ca-trust

Now, for the real test: 现在,进行真正的测试:

env: http_proxy, outer_scheme: https, inner_scheme: http env:http_proxy,external_scheme:https,inner_scheme:http

/t/curl-curl-7_53_1 ❯❯❯ http_proxy=https://proxy.mydomain.com:3127 ./src/curl -s -vvv http://google.com -o /dev/null
* Rebuilt URL to: http://google.com/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (127.0.0.1) port 3127 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [86 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1027 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [262 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* Proxy certificate:
*  subject: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
*  start date: Mar 16 06:43:35 2017 GMT
*  expire date: Mar 16 06:43:35 2018 GMT
*  common name: proxy.mydomain.com (matched)
*  issuer: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
*  SSL certificate verify ok.
} [5 bytes data]
> GET http://google.com/ HTTP/1.1
> Host: google.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
> Proxy-Connection: Keep-Alive
> 
{ [5 bytes data]
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Location: http://www.google.co.in/?gfe_rd=cr&ei=ejTKWLGzM-Ts8AepwJyQCg
< Content-Length: 261
< Date: Thu, 16 Mar 2017 06:45:14 GMT
< X-Cache: MISS from lenovo
< X-Cache-Lookup: MISS from lenovo:3128
< Via: 1.1 lenovo (squid/4.0.17)
< Connection: keep-alive
< 
{ [5 bytes data]
* Connection #0 to host proxy.mydomain.com left intact

env: https_proxy, outer_scheme: https, inner_scheme: https env:https_proxy,external_scheme:https,inner_scheme:https

/t/curl-curl-7_53_1 ❯❯❯ https_proxy=https://proxy.mydomain.com:3127 ./src/curl -s -vvv https://google.com -o /dev/null
* Rebuilt URL to: https://google.com/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (127.0.0.1) port 3127 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [86 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1027 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [262 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Proxy certificate:
*  subject: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
*  start date: Mar 16 06:43:35 2017 GMT
*  expire date: Mar 16 06:43:35 2018 GMT
*  common name: proxy.mydomain.com (matched)
*  issuer: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
*  SSL certificate verify ok.
* Establish HTTP proxy tunnel to google.com:443
} [5 bytes data]
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.53.1-DEV
> Proxy-Connection: Keep-Alive
> 
{ [5 bytes data]
< HTTP/1.1 200 Connection established
< 
* Proxy replied OK to CONNECT request
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3757 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com
*  start date: Mar  9 02:43:31 2017 GMT
*  expire date: Jun  1 02:20:00 2017 GMT
*  subjectAltName: host "google.com" matched cert's "google.com"
*  issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
*  SSL certificate verify ok.
} [5 bytes data]
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
> 
{ [5 bytes data]
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Location: https://www.google.co.in/?gfe_rd=cr&ei=hDTKWJXlMubs8Aek-6WQAg
< Content-Length: 262
< Date: Thu, 16 Mar 2017 06:45:24 GMT
< Alt-Svc: quic=":443"; ma=2592000; v="36,35,34"
< 
{ [262 bytes data]
* Connection #0 to host proxy.mydomain.com left intact

As is evident from the outputs, there is an SSL handshake with the proxy server first in both cases. 从输出中可以明显看出,在两种情况下都首先与代理服务器进行SSL握手。


Now, I'll rant a little. 现在,我会大声一点。

Many clients (eg: curl = 7.51.0), don't support SSL/TLS connection with the proxy itself and throw an error of the sort: 许多客户端(例如:curl = 7.51.0)不支持与代理本身的SSL / TLS连接,并会引发以下错误:

$ https_proxy=https://proxy.mydomain.com:3128 curl -vvvv https://google.com
* Rebuilt URL to: https://google.com/
* Unsupported proxy scheme for 'https://proxy.mydomain.com:3128'
* Closing connection -1
curl: (7) Unsupported proxy scheme for 'https://proxy.mydomain.com:3128'

Then, there are clients (eg curl=7.47.0), which would just ignore non-supported schemes in the proxy URL and that would mislead people into believing things about what they accomplished. 然后,有一些客户端(例如curl = 7.47.0),它们只会忽略代理URL中不受支持的方案,并且会误导人们相信他们所完成的事情。 In general, they would never connect to proxy server over SSL/TLS, even if the variable explicitly specifies the scheme as 'https' and fallback to using unencrypted connection with the proxy server. 通常,即使变量将方案显式指定为“ https”并且回退到与代理服务器使用未加密的连接,它们也永远不会通过SSL / TLS连接到代理服务器。

Then there are other clients (eg wget v1.18), which would confuse us further: 然后还有其他客户端(例如wget v1.18),这会使我们进一步困惑:

  • In the following case, the error message is misleading, because the scheme can hold the value https:// even for a HTTP request to the outside world (as shown in the example above, using squid), since we want the connection to the proxy server to be over SSL/TLS. 在以下情况下,错误消息具有误导性,因为该方案即使对于外界的HTTP请求也可以保留值https://(如上例中使用squid所示),因为我们希望连接到代理服务器通过SSL / TLS。

     http_proxy=https://proxy.mydomain.com:3128 wget http://google.com Error in proxy URL https://proxy.mydomain.com:3128: Must be HTTP. 
  • Not only this, but the confusion increases, when it falls back, make us believe that it is probably connecting to the proxy server over SSL/TLS, when actually it is not, and also making us think that https:// in the scheme should only work when the inner protocol is also https:// 不仅如此,而且当它回退时,混乱会加剧,这使我们认为它可能通过SSL / TLS连接到代理服务器,而实际上却不是,并且使我们认为方案中的https://仅当内部协议也是https://时才起作用

     https_proxy=https://proxy.mydomain-research.com:3128 wget https://google.com --2017-03-16 11:21:06-- https://google.com/ Resolving proxy.mydomain-research.com (proxy.mydomain-research.com)... 10.1.1.7 Connecting to proxy.mydomain-research.com (proxy.mydomain-research.com)|10.1.1.7|:3128... connected. Proxy request sent, awaiting response... 301 Moved Permanently Location: https://www.google.com/ [following] --2017-03-16 11:21:07-- https://www.google.com/ Connecting to proxy.mydomain-research.com (proxy.mydomain-research.com)|10.1.1.7|:3128... connected. Proxy request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: 'index.html' 

For reading more about the security aspects of connecting(and not connecting) with the proxy server over TLS/SSL, visit: https://security.stackexchange.com/a/61336/114965 要了解有关通过TLS / SSL与代理服务器连接(和不连接)的安全方面的更多信息,请访问: https : //security.stackexchange.com/a/61336/114965

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM