Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
But if the user accepts a bogus certificate, is the data transaction between the client and server at least secure/encrypted? As pointed out by Wim in Post #11
If the client accepts a bogus certificate, the transaction is still encrypted just fine. The problem is that the client cannot trust the program at the target to honor any (implied) committment to behave responsibly with the data supplied.
These snippets are what caught my attention.
"Some sites, especially those operated by hobbyists, use self-signed certificates on public sites. Using these provides protection against simple eavesdropping, but unlike a well-known certificate, preventing a man-in-the-middle attack with a self-signed certificate requires the site to make available some other secure method of verifying the certificate."
"A common misconception among credit card users on the Web is that https: fully protects their card number from thieves. In reality, an encrypted connection to the Web server only protects the credit card number in transit between the user's computer and the server itself. It doesn't guarantee that the server itself is secure, or even that it hasn't already been compromised by an attacker."
What I got from this, is that the certificate is reponsible for 'securing' the server-side, as in verifying the authenticity of the site, but not really data encryption during transaction. Right?
We must keep authentication and encryption distinct in our minds. Authentication assures both parties that they are talking to whom they think they are talking to, while encryption assures both parties that their conversation is not being listened in on by a third party.
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.
What I really care about at the moment, is that the users can transfer username,password securely from client to server. I want the transaction to be secure. Lets not care if my server can be trusted for now.
As I tried to point out gently in a previous post, from the client's point of view, it does not matter what the client thinks about whether your server can be trusted. If he receives a certificate that does not match the destination he was trying for, prudence dictates that he should not pursue the transaction, because he may not be talking to your server at all; it could be some hijacker in Lower Slobbovia, for all he knows.
So with my current flawed configuration, is the transaction between the client and server secure at all?
Or is the certificate essential for a secure encrypted transaction? If so, even with a bogus certificate, is the transaction secure? (same question as the 1st paragraph really).
Sorry if I'm being 'slow', cos i am.
In the narrow sense, such transactions are 'secure'. They just cannot be trusted, because the target cannot be authenticated. Eavesdroppers will (almost) certainly be frustrated by the SSL protocol, so the exchange of user/password data will not be completely open to theft. But if I were an attacker trying to acquire passwords for your site, I would mount a DNS hijack attack, redirecting queries to my server, where the user would (all unknowing) send username/password pairs to me, which I could then use to do any sort of mischief that occured to me.
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.
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:
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:
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?
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.