#ForwardProxy

[captain-deepi31-naresh]

If you’ve ever been part of a school, company, or other similar organization, you’ve likely used a web proxy server. But what does “proxy” even mean? In this article, we define proxy servers, explain how web proxies work, and, most important, show you exactly what you can and cannot expect from proxies in terms of online privacy and security.]

[ujiki-oo]

#Proxy #Proxyserver #Forwardproxy #PublicProxy

 I would like to talk about whether it is foolish or clever to use faithfully the proxy server that governments, companies and universities use. If you continue to use incompetent proxy servers for which you are willing to pay, it is an idiot that cannot be saved. Can you read the text of an article before it comes to your mind? The two images on the right are the images near my WordPress title. Compare the two images and remember which one your browser displays. You can guide whether your choice is right or a dire choice!

[xlong1984-blog]

五分钟入门V2Ray

https://kirikira.moe/post/19/

从十九大开始，GFW的节奏变成了每隔一段时间就开始IP大屠杀，每次屠杀结束Telegram的自建梯子用户和机场主都是一片哀嚎，同时流言四起，也有大批人从ss/r转投V2Ray。在前两次屠杀的时候，我都成功躲过一劫，然而这一次还是免不了躺枪了三个ip，其中两个压根不是梯子，一个是曾经喜欢的梯子但现在已经废弃很少用了。看到这副惨状，默默地忍着眼泪给第三个ip套上cdn将就用着，另外两个就先放置play了。

在进入今天的主题之前，有几个明显的谣言即使没有技术，智商逻辑正常的我们也可以判断的出来：

SS/R已经被精准识别了。

这话你先去跟各大机场主说去。况且真能精准识别的话，还用得着ban ip段殃及池鱼？

SS/R的http和tls混淆已经被破解了。

混淆这玩意本来就不是过墙��的而是躲某些地区的QoS用的，用混淆本来目的就是为了增加特征而不是减少特征。

用了V2Ray就不会被墙了。

那我非梯子被墙去找谁呢。

用V2Ray就必须用WS+TLS+Web（+CDN），不然没意义。

我可去你妈的吧.jpg

好了，那既然标题是五分钟入门V2Ray,我们就赶快开始吧。

第1步：校准时间

当你使用VMESS协议是，必须保证本地和服务端的时间差不超过一分钟。实际上，这个时间差对比的是timestamp,为图省事，我们直接把时区修改了

$cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime $date --set="2018-2-16 16:23:30"

其中第二行当然要改成你当前的时间了。

第2步：安装V2Ray

不同于SS/R有五花八门的一键脚本，V2Ray官方就有提供一键脚本，支持CentOS7/Debian全系列（含Ubuntu）

$bash <(curl -L -s https://install.direct/go.sh)

第3步：选择合适的协议

之前在V2Ray群里有一位大佬做了一张推荐配置图:

就我个人来说，我推荐一般情况使用TCP + TLS （+None加密） + 443端口，当你已经有web服务部署时使用WebSocket + TLS + web server, (或者当服务器ip被墙想要用cdn拯救一下的时候使用WebSocket + TLS + web server + cdn)。下面就介绍这两种配置。

4.1 TCP+TLS

不考虑自签证书，一般我们要使用TLS的话需要先有一个域名，将它解析到服务器的ip上来，接着我们需要对应域名的证书和密钥。

域名建议去namecheap或者别的域名服务商买个便宜的域名，比如.win也就几块钱一年，如果申请.ml,.tk这样的免费域名以后万一被回收了反而麻烦。有一个域名之后，其他的服务器就可以用子域名而不用重新申请了。

证书的话，我们当然可以老老实实去签发机构手动申请，也可以偷懒用acme.sh来申请，还可以利用Caddy自动申请证书的特性来获得证书。反正是翻墙用小鸡，多配置一个Caddy的https代理和反向代理岂不美哉～下面就顺便讲一下Caddy，如果已有证书或者不准备用Caddy的可以跳过。

安装Caddy:

$wget https://raw.githubusercontent.com/ToyoDAdoubi/doubi/master/caddy_install.sh && chmod +x caddy_install.sh && bash caddy_install.sh install http.forwardproxy

caddy虽然也有官方提供的安装脚本，不过Toyo的脚本里包含了systemd service配置，所以我们就用他的来装啦。安装完后在默认的service里，Caddy的配置文件位于/usr/local/caddy/Caddyfile.编辑Caddy：

$vim /usr/local/caddy/Caddyfile https://sub.example.com:8443  { gzip tls kiri_so@outlook.com #这里是你的邮箱 proxy / https://www.google.com #这行表示反代咕果。 forwardproxy {    basicauth kiri 41888438  # 这里是https正向代理的账号密码    hide_ip    probe_resistance proxy.kiri.localhost  # 这行是防探测用的, 后面随便填一个不存在的域名    } }

编辑完以后重启Caddy:

systemctl restart caddy

在上面的配置文件里，我们让Caddy负责监听8443端口（8443端口是和443端口等同的https用端口，由于我们把443预留给了V2Ray,所以就把8443给Caddy了），同时负责申请证书、反代咕果、提供正向代理。现在，在配置V2Ray之前，你就已经可以在浏览器里通过访问https://sub.example.com:8443使用咕果，以及在SwitchyOmega里设置https代理（服务器sub.example.com,端口8443,账号kiri,密码41888438）直接访问想上的网站啦。如果浏览器现实 ERR_TUNNEL 的话, 就访问一下 http://proxy.kiri.localhost 来触发验证.

如果浏览器可以通过https访问你的域名，那么也说明Caddy也为你申请好了证书。证书和密钥可能位于：

/.caddy/acme/acme-v01.api.letsencrypt.org/sites/sub.example.com/sub.example.com.crt /.caddy/acme/acme-v01.api.letsencrypt.org/sites/sub.example.com/sub.example.com.key

如果不是的话，可以用find / -name *sub.example.com*来寻找

接着我们来配置V2Ray，欢迎使用模板项目vTemplate来寻找对应的配置模板。比如现在我们要用TCP-TLS：

$cd /etc/v2ray/ $wget -O config.json       https://raw.githubusercontent.com/KiriKira/vTemplate/master/TCP%2BTLS/config_server.json $vim config.json

我们需要改三个地方：uuid,tls_certificateFile和tls_keyFile,相信视力正常的你能找到这三个地方在哪里。uuid我们可以在线生成,或者直接在命令行中生成。使用uuidgen或者请python帮我们生成：

$python >>> import uuid >>> uuid.uuid1()

上面是调用了python的命令行, 如果写成一句命令的话就是:

$python -c "print(__import__('uuid').uuid1())"

编辑完config.json以后，使用systemctl restart v2ray来重启V2Ray，再用systemctl status v2ray来看看V2Ray启动成功了没有。如果启动失败的话，大概率是你的json格式不对，请检查一下 逗号 的大小写、有没有忘记加 引号 之类的细节。这样，V2Ray服务端就配置完了。

4.2 WS+TLS+Web

当我们已有网站部署并且准备将 V2Ray 隐藏在网站后面时，就可以让 Web Server，例如 Nginx/Caddy 来把流量分流给V2Ray。重申一遍我的立场，如果没有真网站就不要放个假网站上去再用WSS，因为WS往往会比纯TCP-VMESS要慢(小薇姐姐的解释: 理论上不会比TCP更快, 但是实际体验如果有明显差距就是配置不当的原因)，即使要放也请放个Aria2面板之类的有点用处的东西上去而不是放个毫无意义的静态网页。

我们采用根据path分流的方法，例如通过设置设置Nginx/Caddy，将所有对https://sub.example.com/test/ 的流量传给后端的V2Ray, 而所有不是/test/ 的请求则正常应答，这样在外部看来就是完全正常的一个网站流量了。

如果使用Nginx, 在配置文件里添加：

location /test/ {        proxy_redirect off;        proxy_pass http://127.0.0.1:1234; #把V2Ray监听在1234端口        proxy_http_version 1.1;        proxy_set_header Upgrade $http_upgrade;        proxy_set_header Connection "upgrade";        proxy_set_header Host $http_host;        }

如果用Caddy, 就添加：

proxy /test/ 127.0.0.1:1234 {    websocket    header_upstream -Origin  }

最后再配置V2Ray：

$cd /etc/v2ray/ $wget -O config.json       https://raw.githubusercontent.com/KiriKira/vTemplate/master/websocket%2BCaddy%2BTLS\(use%20path\)/config_server.json $vim config.json

这次我们要修改的就只有config.json中的uuid，注意TLS的拆装由Web Server完成，不需要再在V2Ray中配置TLS！生成uuid的办法跟$4.1一样。

第五步：配置客户端

最后我们就来配置V2Ray的客户端啦。

Android: BifrostV(推荐)、 V2RayNG(推荐)、 Actinium、 V2RayGO

ios: Kitsunebi、 Pepi、 Shadowrocket

安装客户端以后该填啥填啥，我相信你能看的懂。至于在电脑上使用的话，推荐直接用Core，客户端json文件也可以参考vTemplate

到这���就大功告成啦～～～最后祝您，身体健康……啊不对，祝您参考更多V2Ray的文档和教程：

官方文档 : https://v2ray.com

白话文教程 : https://toutyrater.github.io/

模板 : https://git.io/kiri

[josidel]

Browsing Without a VPN

Network environments are growing increasingly hostile. Freedoms of speech, religion, and press are being diminished. The right to privacy is challenged globally on multiple fronts. For these and other reasons, you may find it valuable to add an extra layer of security and privacy to your Internet connection.

This is typically done using VPNs, SSH tunnels, or just regular ol’ HTTP proxies. However, they each have their problems:

VPN: When used primarily for anonymized/proxied browsing, VPNs are less than ideal. VPN traffic is fairly obvious on the wire, especially with deep packet inspection, which is why governments are able to block (most) VPNs if they try to. VPN providers often advertise anonymity and protection while running sketchy operations that log your activity or don’t properly secure your traffic. To make matters worse, setting up your own VPN correctly can be difficult. Conflicting, incompatible protocols sometimes require installing extra software depending on the VPN you connect to.SSH tunnel: SSH is available on most Linux machines (and Macs), but like VPNs, SSH traffic is pretty easy to identify — mostly because it runs on port 22. Running services on a different port is not always an option because of firewall restrictions. Even if you multiplex multiple protocols on the same port, SSH traffic looks different from HTTPS. Also, SSH is known for being unreliable when the network drops out (“broken pipe” anyone?), and slow every other time. But at least SSH tunnels are much simpler to create than setting up a VPN.HTTP proxy: The obvious requirement here is for HTTPS at the very least, but unless you properly automate a Let’s Encrypt certificate, you have to go to some work to maintain the HTTPS server. Pretty much all HTTP proxies these days do not support HTTP/2, and it’s pretty easy to tell (from the client-side) if a server is acting as a forward proxy. I should not even have to mention that trusting random HTTP proxies on the Internet isn’t a great idea.

This article will show you how to secure your Internet connection in a way that overcomes these weaknesses. You will learn how to set up the Caddy web server as a secure forward proxy using the http.forwardproxy plugin, which has these advantages:

HTTPS enabled by default. All certificate maintenance is automated. It just works!Full-duplex HTTP/2. This proxy speaks HTTP/2 both ways, which gives you faster page load times.End-to-end encryption. For sites that use HTTPS, your connection to the origin is E2E encrypted. Even the proxy server cannot decrypt your connection between your computer and the origin site. Once the HTTPS tunnel is established with the proxy, it simply shuttles bytes in a two-way stream. Underlying TLS connections remain intact. (Even a nefarious proxy can’t read the content of your underlying HTTPS traffic, but you should still only use proxies you trust. There’s more to traffic than its contents.)Probe resistance (experimental).This feature hides the proxy behavior of the server from everyone except to those who already know how to access it and are authorized to use it. Only a secret link specified by you (the server operator) exposes the authentication prompt.Innocuous traffic patterns. Since this proxy is not a VPN or SSH tunnel, it blends in better with the rest of HTTPS traffic.Standard ports. Where VPN ports and SSH port 22 are blocked by firewalls, port 443 is almost always allowed because accessing the Web is so standard for most use cases. (But you can still customize the port.)Hides your IP address. With just one line of config, this proxy will not add the user’s IP to the HTTP “Forwarded” header. (Note that there are ways around this out of the proxy’s control, like WebRTC in browsers.)Access controls. You can specify users and passwords to restrict access to the proxy, as well as a port whitelist for the proxy.Easy to set up! Best of all, this proxy is easy to get running and hard to get wrong because of sane defaults and automatic HTTPS. Caddy is designed to be easy to use to reduce the potential error surface of misconfigurations.

In particular, we’re interested in exploring how helpful this software software could be in circumventing censorship. It definitely needs more careful vetting (read on) but we hope people will try it out in low-or-no-risk scenarios.

This plugin was developed by Sergey Frolov while interning at Google and the source is available on GitHub.

Presented “As-Is”

I make no guarantees; use this tutorial and the server software at your own risk. There are a number of edge cases that ultimately depend on your client and your threat model; see especially the warning in the client configuration section below.

This technique is still fairly new. We want to make it even safer. So we do not recommend using it in high-risk situations. If you find a way to improve it, though, please contribute your feedback, issues, and pull requests!

Setting up the Server

First, you’ll need a machine that is accessible with a public IP address. Home servers can work if you forward the port(s) properly. You can also rent a cloud instance from any reputable cloud provider for a few dollars per month. Once you have such a machine, here’s what to do:

Download Caddy with the http.forwardproxy plugin included. To do that, make sure you select it in the plugins list on the download page!

Install Caddy; this is as easy as extracting the archive and putting the binary in your PATH, or using the one-line auto-installer script shown at the bottom of the download page after you select the plugins you want.

Make a file called Caddyfile that looks like this:

example.comroot /path/to/your/site forwardproxy { basicauth user pass probe_resistance secret.localhost hide_ip }

You must replace:

example.com with the actual domain name pointed at your machine/path/to/your/site with the actual path to the root of your site (or an empty or decoy folder if you have no site)user pass with a username and password of your choice (otherwise anyone could use your server!)secret.localhost with a custom, secret hostname to enable probe resistance; strongly recommended to end with “.localhost”

Then run caddy in the same folder as your Caddyfile. After a few seconds, your probe-resistant, IP-hiding, full-duplex, HTTP/2 proxy will be running with a fully-managed TLS certificate from Let’s Encrypt!

The default port is 443 (the HTTPS port) unless you specify otherwise. Read more about the Caddyfile if you want to customize further.

Setting up the Client

Now how do you use your proxy server? With a client, of course!

There are several ways to do this. For example, if you want to secure your web browsing in Chrome, you can use an extension like Proxy SwitchyOmega to configure the connection. Firefox has some network options built into its settings. You can also configure your entire OS or mobile phone to use the proxy for all applications (except those that are specifically configured to not use your OS’ proxy settings). However, we found only Chrome+SwitchyOmega to be reliable, which we explain below.

** WARNING! A weakness in any part of the proxy configuration could leak information. Even if your proxy server is secure, your client may not be. Clients which do not honor the proxy settings for all network traffic could put you at risk. This includes major browsers and operating systems. For example, browsers don’t put WebRTC requests through the proxy (by design, sigh). One way to mitigate this risk somewhat is to use a VM that tunnels all traffic across a virtual NIC. This is obviously more involved, so act according to your threat model. If you just need basic public Internet cafe privacy to check your email, maybe the VM is overkill. That’s up to you.

Chrome + SwitchyOmega

This was the most reliable and simple client configuration I tried.

Install SwitchyOmega. It comes with an example proxy profile (on the left) which you can modify, or you can create a new one. In the table, select “HTTPS” for the “Protocol” field and type in your domain name and the port:

Click the lock icon by the port and enter your username and password:

After save your credentials, click the green “Apply Changes” button to the left:

You can turn on the proxy by clicking it from your menu:

Congrats! Now all your Chrome connections are proxied securely through your server.

Firefox

Like Chrome, Firefox also has a SwitchyOmega extension. I would suggest using extension first, since you are likely to have more success than with Firefox’s built-in network settings. The instructions are nearly the same as above.

Using Firefox’s built-in network configuration settings, I was not able to get this working in Firefox (on macOS 10.12.6) for a server with probe_resistance enabled. It appears to be a bug in Firefox. Firefox hangs when loading the page, for several minutes — and spins the CPU at 100%. Even after closing the application, my computer ran sluggish for almost a day until I found the firefox process still running in the background still using 100% of my CPU. Other than using the SwitchyOmega extension, there are two other workarounds on Mac: Use Chrome, or disable probe resistance.

To change Firefox’s built-in network configuration, go to Menu -> Preferences:

Then Network Proxy, and click “Settings…”:

Here you have a few options. You can “Use system proxy settings” which should use your operating system’s proxy settings. You can specify a “Manual proxy configuration” where you enter the hostname and port your proxy is listening on (EDIT: As noted in a comment, this will not utilize TLS-to-proxy. So don’t do this, use the PAC file instead — next sentence). Or, if you use the serve_pacserver setting, you can specify its URL:

Save your settings, and you should be good to go. Maybe. Good luck!

macOS (and/or Safari)

This will change the proxy settings for the entire system. Make sure this is really what you want to do instead of using the proxy only with your web browser!

Unfortunately, I was not able to successfully get macOS’ system-wide proxy configurations to work reliably, even with probe resistance / authentication turned off. I’ve also been told that some previous version(s) of macOS (or OS X) could even kernel panic when using a TLS proxy. (But I was able to get Firefox and Chrome using the proxy successfully, as described above.)

If you want to experiment with getting system-wide proxy config working, open System Preferences and go to Network. Choose your active network interface on the left and click the “Advanced” button in the lower-right. Click the “Proxies” tab. I tried both the “Automatic Proxy Configuration” (where you give the .pac file URL) and the “Secure Web Proxy (HTTPS)” options. Both had different but equally disappointing levels of support in various applications.

Linux (Ubuntu 16.04 Desktop)

Good news! Setting Linux’s system-wide proxy settings worked fairly well in my testing.

Open Network preferences and select “Network Proxy”. Choose “Automatic” for the Method, and type the configuration URL of the .pac file. (You’ll have to enable serve_pac on your server configuration inside the forwardproxy directive; choose a secret URL to serve the file on, so it doesn’t defeat your probe resistance). If you don’t want to use a .pac file, you can choose “Manual” for the Method and enter your hostname and port (443 probably) — use it for all protocols.

Since there isn’t a way to configure the system proxy to send credentials, you need to use your secret link to authenticate. Only the secret link will prompt the browser to enter credentials. You may have to do that every time you re-open your browser.

So open your web browser (maybe double-check its network configuration if you’re not sure) and go to your secret link. Enter your credentials, and you’re good to go!

Android

This method works for WiFi networks. I haven’t looked into how to set a proxy for the cell network. It requires using a .pac file. If you haven’t already, enable the serve_pac option within the forwardproxy directive. For probe resistance, I recommend specifying a secret URL to serve it on, rather than the default /proxy.pac.

Go to your WiFi settings and long-tap on the current network. Choose “Modify Network”:

Under Proxy, choose “Proxy Auto-Config” and type the URL to your .pac file:

Save settings. With probe resistance enabled, you’ll have to navigate to your secret link in your browser to expose the authentication prompt. Then you should be good to go. Remember: this doesn’t apply to the cell network.

Windows

These instructions are for Windows 7, but the same basic idea works in more recent versions of Windows. I’m borrowing these instructions from Sergey’s blog (with permission) because I don’t have Windows:

Control Panel → Network and Internet → Internet Options → Connections → LAN settings → Check “Use a proxy server…” and paste your “https://yourserver.com” in Address and “443” in port. Don’t lose “https://” in Address, Windows likes to remove it when you open LAN settings window again.

Image borrowed with permission from Sergey Frolov: http://ift.tt/2A2ZRSL

Conclusion

Caddy’s http.forwardproxy plugin is a promising alternative to using VPNs or SSH tunnels for certain tasks and for certain threat models. We hope this technology will help provide greater access to the Web to more people because of its unique properties and ease of use. However, client support for TLS-to-proxy must improve and become more reliable and predictable. We hope that client support for secure proxying will improve and become more robust in the future.

Thanks to Eric.

via Blogger http://ift.tt/2z9ZI0O