Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a VPS. How do I connect to my server through HTTPS protocol and redirect my browser connections to the HTTPS connection?

Currently I use SSH tunnel but it's too slow.

share|improve this question
1  
What are you trying to do? Are you trying to redirect plain HTTP requests to HTTPS? –  cjc Apr 10 '12 at 20:06
    
Perhaps OpenVPN is the best solution, do you have to tunnel over HTTPS? –  kwarrick Apr 12 '12 at 5:27
    
@solo: Yes!..... –  hknik Apr 12 '12 at 8:40
    
How are you creating the SSH tunnel? With ssh -D? (creates a SOCKS proxy) How fast is your connection to the other end of the SSH tunnel? –  Mikel Apr 16 '12 at 2:36
add comment

7 Answers 7

Is the https server apache? I don't fully understand your situation, but if you have mod_proxy, you might able to do what you want.

share|improve this answer
    
Yes. Server is running with apache. But I don't know how to connect... –  hknik Apr 6 '12 at 20:31
    
I was thinking mod_proxy would be helpful if you had something in a DMZ type environment, but it sounds like this is not possible. If there a http server running on the host you ssh in to? Have you asked your service provider if they can do anything, or do they just suggest ssh tunnels? –  zje Apr 7 '12 at 5:44
    
server is running with apache –  hknik Apr 10 '12 at 16:34
add comment

I do something like this using OpenVPN. My laptop and cellphone can connect to my server at home using SSL over a TCP connection on port 443. This is really useful when I'm at stodgy places that don't let you use any ports besides 80 and 443. Here's a simple configuration that accomplishes this on the server:

port 443
proto tcp
dev tun
server 10.44.3.0 255.255.255.0
ca ca.crt
cert cloud.crt
key cloud.key
dh dh2048.pem
script-security 2
push "redirect-gateway"

Then you tell the server to perform NAT on packets coming from VPN clients:

iptables -t nat -A POSTROUTING -s 10.44.3.0/24 -o eth0 -j MASQUERADE

After I get connected, the networking route on my portable device looks like this:

briankb@ubuntu:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.94.0.9       0.0.0.0         UG    0      0        0 tun0
192.79.68.0      0.0.0.0         255.255.255.128 U     1      0        0 eth0
10.94.0.1       10.94.0.9       255.255.255.255 UGH   0      0        0 tun0
10.94.0.9       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
121.119.173.12   192.79.68.1      255.255.255.255 UGH   0      0        0 eth0

The first line says that default gateway of the client is the VPN server, so all traffic is sent over it. The next line is the subnet I'm currently using (college wifi). The third and fourth line are the VPN subnet/route, and the last line says use the current WAN interface to send packets to the VPN server.

For instructions on setting up OpenVPN, see the How to guide.

share|improve this answer
    
I was lazy and just set my ssh to use port 443. –  Rob Apr 16 '12 at 16:11
add comment

I'm using Squid as proxy server and Stunnel as SSL wrapper. It has very good performance due to caching.

Squid Configuration

After installing Squid, follow Squid Documentations and configure it. Here is sample configuration:

http_port 3193 transparent

cache_dir ufs /var/cache/squid 128 16 128
cache_mem 1 MB
maximum_object_size_in_memory 512 KB
maximum_object_size 1 MB

visible_hostname hostname.com

hierarchy_stoplist cgi-bin ?
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

acl localnet src 10.0.0.0/8     # RFC 1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC 1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC 1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

auth_param basic program /usr/libexec/squid/pam_auth
auth_param basic children 5
auth_param basic realm Squidy
auth_param basic credentialsttl 4 hours

acl password proxy_auth REQUIRED

http_access allow manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow password
http_access allow localhost
http_access allow localnet
http_access deny all

via off
forwarded_for off

request_header_access Allow allow all
request_header_access Authorization allow all
request_header_access WWW-Authenticate allow all
request_header_access Proxy-Authorization allow all
request_header_access Proxy-Authenticate allow all
request_header_access Cache-Control allow all
request_header_access Content-Encoding allow all
request_header_access Content-Length allow all
request_header_access Content-Type allow all
request_header_access Date allow all
request_header_access Expires allow all
request_header_access Host allow all
request_header_access If-Modified-Since allow all
request_header_access Last-Modified allow all
request_header_access Location allow all
request_header_access Pragma allow all
request_header_access Accept allow all
request_header_access Accept-Charset allow all
request_header_access Accept-Encoding allow all
request_header_access Accept-Language allow all
request_header_access Content-Language allow all
request_header_access Mime-Version allow all
request_header_access Retry-After allow all
request_header_access Title allow all
request_header_access Connection allow all
request_header_access Proxy-Connection allow all
request_header_access User-Agent allow all
request_header_access Cookie allow all
request_header_access All deny all

It listens port 3193 tcp. Then caching options come, Some acl commands and auth_param for PAM authentication (You probably don't want open proxy and lost your VPS for spam reports). request_header_access lines are not required. They give you better anonymity.

Stunnel Server Configuration

Install stunnel on server. Here is sample configuration:

setuid = stunnel
setgid = stunnel

CAfile = /etc/stunnel/certs.pem
CRLfile = /etc/stunnel/crls.pem

[proxy]
accept = 8888
connect = 127.0.0.1:3193

Probably certification files made on stunnel installation. check the file path in CAfile. It simply listens to port 8888 tcp and redirects decrypted stream to Squid. So let be sure it's reachable:

iptables -I INPUT 1 -p tcp --dport 8888 -j ACCEPT

You don't need to squid listening port be world reachable anymore.

Stunnel Client Configuration

Install stunnel on your local machine and change this configuration to your needs:

setuid = stunnel
setgid = stunnel
pid = /var/run/stunnel/stunnel.pid

[poxy]
accept = 8123
connect = server_ip:8888
client = yes
libwrap = no

Replace server_ip with appropriate value. then start Squid on server and Stunnel on client and server. set proxy as localhost:8123 in your browser. If everything work, you must be prompted for username and password.

share|improve this answer
add comment

My crystal ball says you should take a look at http://www.stunnel.org/static/stunnel.html

In case the ball is wrong, it won't hurt anyways.

share|improve this answer
add comment

I have never set up anything on a virtual host, but here is some information on general HTTPS:

HTTPS uses a combo of HTTP and SSL (see the wikipedia article here: http://en.wikipedia.org/wiki/HTTP_Secure). HTTPS isn't really its own protocol per-se but rather normal HTTP running on an SSL tunnel.

HTTPS uses CA's (Certificate Authories) and PKI (Public Key Infrastructure) to ensure that users can 'trust' the site. You must create a public key certificate for your web server, and that must be signed by a trusted CA (such as VeriSign). To get a trusted certificate it can cost you a yearly fee to maintain.

If you don't go through a trusted CA, users will get a warning when they attempt to connect to your site. This can often times lead users to stray from your site because they might see it as a security risk.

Also, keep in mind that while HTTP uses port 80 by default, HTTPS uses 443 so if you have any port forwarding/port blocking you will have to ensure that is open for you to connect. To use HTTPS you will also have to ensure you type it into the URL when you navigate to the site, otherwise it will likely default to using HTTP.

EDIT: Here is a good introduction to how HTTPS operates: http://securityworkshop.blogspot.com/2009/01/how-httpsssl-works-part-1-basics.html

share|improve this answer
add comment

Simply enable HTTPS and mod_alias in Apache, and add a redirect rule like the following:

<VirtualHost *:80>
                 .
                 .
                 .
    Redirect permanent / https://yoursite.com/
</VirtualHost>

The default configuration varies between OSes/distributions, so I can't be more specific than that. It's better to specify your OS and software versions on the questions so you can get better answers ;-).

share|improve this answer
add comment

Connect to your server through SSH and set up port forwarding: ssh -L 80:localhost:80 username@hostname. Remote port 80 (your webserver) will be tunneled over SSH to you PC's port 80. Now point your browser to http://localhost/

You may have to extend a line in your /etc/hosts file: 127.0.0.1 hostname

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.