The security during the communication is the same.
When a user access the site, he accepts the certificate and then all is the same as a trusted certificated, signed by Verign and so on. |
Quote:
Quote:
The certificate exchange speaks only to the first point. A self-signed certificate for the website that a client requested may or may not be acceptable, but that is the client's choice. A browser will complain when a self-signed certificate is received from a website the client requested, and will ask for permission to proceed. If, after investigating the certificate (perhaps by looking at the digest, and verifying somehow that it matches one that the client thinks is the right one), the client accepts the certificate as genuine, all is well thereafter. An entirely different problem is presented when access to a website via HTTPS produces a certificate for a different target. Here, the client must not only evaluate whether the target is trustworthy, but also the risk that the transaction may have been hijacked to a completely different destination. Accepting such a certificate is a much larger leap of faith, IMHO. Quote:
Quote:
|
Hi, I've been reading this with interest to find out more about the apache https proxy configuration but was hoping I might be able to go a little off track and add some of my basic understanding with regard to the certificate process in order to try and help robin.com.au.
This relates to PKI, (public key infrastructure). In the corporate world a company would send a certificate request to the likes of thawte or verisign. They’d confirm your company is real and if it’s all bonified they’d create a certificate for you signed by them and you’d implement it on your server. These people are known as the Certificate Authoritiy or CA. Some of us folk who don’t want to pay all our hard earned cash out for a certificate take a different root and create our own self signed certificate. You create your own CA certificate and use this to sign the certificate you’ll use to encrypt your link. You’ve, still got a certificate that’s encrypting the data in exactly the same way. So what’s the difference:- As you know, clients will get a security warning with your certificate but won’t with one signed by a trusted commercial CA. This is because their public bit of the CA certificate is built in to most of the browsers around the world whereas yours isn’t. So effectively the CA has confirmed that you’re the company you say you are and have issued a certificate accordingly. With your certificate it’s only you that says you are who you say you are. If a client chooses to still connect to you with this warning then they have no guarantee that it’s really you as it could be any other Tom, Dick or Harry that created their own certificate with the same name details as you. Hence, this is the reason you’ve got a security flaw with a self signed certificate. There is a way round this but depends on what you’re trying to achieve. The public part of the CA certificate that you signed your own certificate with can be exported by you. The client can then install this on their browser. Hey presto no more message saying you’re not trusted. VERY IMPORTANTLY you’ll only have exported the public part of your CA certificate. The private key is kept by you. Now if anyone creates a certificate with the same name details as you they won’t have signed it with the same private key as you so now the client will get a security warning but it will be legitimate. The issue is how to distribute your CA public certificate securely. On an intranet you could put it into the browser at build time or deploy it by software distribution but out in the internet world it’s not so easy. I’d suggest if the clients are all part of your company then this is an option but if they’re not it’s too involved to expect end users to start installing certs in their browsers. The good news is that if you do find a way to distribute it you can use your same CA certificate to sign future certificates for your websites so that you don't have to distribute it again. Thought this link was quite useful:- http://www.debian-administration.org/articles/284 |
In Reading all these threads, they help a lot. But these confused me on one account. From what I have read previously I understand that for each site using SSL needs its own IP, but NOT its own port? I can have the following:
1.2.3.4 --> 192.168.1.10 (port 443) 1.2.3.5 --> 192.168.1.11 (port 443) 1.2.3.6 --> 192.168.1.12 (port 443) And then I can register 3 SSL certificates with the public (external) IP's of (1.2.3.X) Can someone just confirm this for me please. THanks :) |
You are correct. Each HTTPS site (using SSL) needs its own IP address (actually its own address/port combination, but since random users *always* expect to make initial contact with a secure server on port 443, this reduces to 1 IP address per site).
However, you don't need to maintain that separation once you go through address translation. Instead, you can map several external IP addresses to a single internal server this way: 1.2.3.4:443 -> 192.168.1.12:443 1.2.3.5:443 -> 192.168.1.12:10443 1.2.3.6:443 -> 192.168.1.12:12443 1.2.3.7:443 -> 192.168.1.12:13443 Parenthetically, as I re-read the postings today, I noted that I had omitted an important detail in the iptables instructions several months ago: in addition to the entry in the PREROUTING table that specifies the DNAT target and causes a mapping like the one above to occur, it is necessary to specify separately that the translated packet should actually be passed through the firewall: iptables -p tcp -A FORWARD -d 192.168.1.12/24 -dport 443 -j ACCEPT as an example. |
Now im a little confused, and im having trouble implementing this as well.
I have a router doing the DNAT implementation. I know its set up correctly, but my linux servers are accepting any connections. When i go to the public IPs, it doesnt get to the server. I put a managed switch in the LAN and had a DNAT rule to that from a public IP, and I got right to it from the public IP. I turned off iptables on the server just to check, but still nothing. Question is: If I have a router doing the DNAT implementation, is there anything that needs to be done on the server? THanks |
This may be a new discussion, but could also be related to the note I put in my last post on this thread.
In order to make effective contact via HTTPS, the two systems involved must be able to send packets in both directions. This means that the NAT box must not only translate the address/port combination as required, but it must also forward the first packet from the public side to the private side, and then must pass the reply packet(s) from the private side to the public side. Since I don't know anything about your router, I cannot say with any certainty what all is needed to make this all happen. But you may be able to check this out using the program tcpdump on your linux server. Read the manpage, and set up a tcpdump command to monitor any tcp traffic on port 443 (your HTTPS port). Then try making contact through the public IP address. You will get one of several results this way: 1. No data: either you haven't got the tcpdump command right, or the router isn't actually passing your packet to the linux box. 2. 1 TCP packet, with SYN set. The first packet arrived, but was not handled right on the linux box. 3. 2 TCP packets, the first incoming (SYN) and the second outbound (SYN,ACK set): the linux box received the connect request, and replied to it, but the router did not get the return packet sent out to the public Internet. 4. more than 2 packets: I don't know enough to guess why the connection is not working. Good luck. |
All times are GMT -5. The time now is 09:34 AM. |