Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I noticed an intersting thing. Every time when I access a SSL enabled website like chase.com in my company. The SSL certificate is not from a well known CA like VeriSign but the IT department of my company. We use a dynamic proxy (I don't know how to explain but we don't need to set it up in IE->connection section for sure) for every internet access. I was guessing that the proxy changes the SSL certificate to our IT's own certificate.
My guess: Every time a SSL connection start, the proxy take my HTTPS request, get the certificate (let's call it SSL_Chase, for both SSL and the symetric key for data encryption) from the website like chase, change the certificate to our own IT certificate (let's call it SSL_IT) and send it with the respose to me. I fill out the user name and passowrd, my machine using SSL_IT to encrype my data and our proxy get it and unencrype it. Then the proxy encrype it using SSL_Chase and send to chase. So chase think our proxy is me and I think our proxy is chase, except the IT certificate is not from chase (I think most users won't notice it). This means, IT department knows everything we send to chase and chase send to me!!
I was wondering if my guess is possible, from the SSL connection algorithm point of view.
Hope anybody can give me a hint.
Thanks a lot!
It probably goes like this: you have your IT department's certificate as a trusted root certificate on your computer. When you browse to an HTTPS address, the proxy generates a certificate for that site on the fly, signed by the certificate that's trusted by your browser. You then communicate with your proxy, and the proxy communicates with the real site. Both "legs" of the travel are over SSL/TLS, so you're safe from a random man in the middle, but your IT department can theoretically view all the communication.
This is a classical "man in the middle" approach, from a proxy's perspective. It's your browser's responsibility to warn you that the certificate presented doesn't match the site you are visiting.
If you are using IE, your IT department most likely pushed the corresponding CA to you as trusted CA, so your browser trusts it automatically. For other browsers, not using Windows Cert Store, it's also possible, but a bit harder to do. In any way, an unsuspecting user can be led to believe that the information is transmitted in a direct SSL link to Chase, when it's not. In either case, you should still get a browser warning, if the proxy has the corresponding feature for the CONNECT verb.
Yes, a proxy can act like a Man in the Middle.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I built a simple website for my mother's business. There is no login, database, or any sort of form or payment happening on the site. I do not have an SSL Certificate and was wondering if a self-signed one offered by cPanel hosting would suffice? I would hate to shell out money for encryption I don't need yet. The main reason I need it is so that the browsers stop blocking my https connection. Any information I can get on this would be a big help.
Rather than selecting a self-signed SSL Certificate, you better go with the Free/Trial SSL Certificate offered by some of world's leading SSL Certificate authorities like Comodo, Symantec and RapidSSL.
Why no to Self-Signed SSL Certificate?
Not accepted by most browsers
Browser will display untrusted connection error message
Why Free/Trial SSL Certificate?
Compatible with multiple servers and operating system platforms.
Accepted by 99.9% web and mobile browsers (No Error after installation)
It will give trust and confidence to users as the SSL is from verified SSL authority
Increases website reputation over internet.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have a website running on AWS that needs SSL. The website has the functionality that it must by white labelable according to the subdomain accessed. For example, when accessing www.a.the-site.com the website will look different from when it is accessed from www.b.the-site.com, but it is the same virtual host handling both urls. I use an ELB which directs to the EC2 instance (only one instance at this stage) This worked fine when running over normal http.
I followed the step by step tutorial on AWS (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/ssl-server-cert.html and http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-create-https-ssl-load-balancer.html#configure-https-listener) to generate the keys (steps laid out below for ease of reference) and got the certificate from GoDaddy. (Upon pasting the CSR on the GoDaddy website's certificate request process, the correct CN was displayed). The certificate bought was a wildcard certificate, to support different subdomains. I applied the Certificate on the ELB using the AWS website interface, which did not prompt any errors, but now when I access the site over https, I get the SSL error in the browser:
"The security certificate presented by this website was issued for a different website's address."
Investigating the Certificate on https://www.sslshopper.com shows the following:
It states that none of the common names match, yet the common name in the chain is correct (*.the-site.com)
I can also post the steps followed to create the private key and CSR, but I have not received any indication that these are incorrect. It seems like the CN *.the-site.com is not resolving www.a.the-site.com. Can anyone shed some light on this?
#Michael - sqlbot was correct, the wildcard certificate only checks for a single domain. I changed my domain settings to not redirect to www.a.example.com, but rather a.example.com (dropping the www subdomain) and all is working as expected.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Our company recently implemented Zscaler proxy filtering, which I just learned uses a root certificate pushed out to all of our machines to forge SSL certificates for mitm filtering of our traffic. Personally I'm not happy about this, but we do a lot of sensitive work, so I'm not going to complain.
But now I'm noticing they don't seem to be doing it consistently. For instance, if I go to Facebook on the work network, the certificate is signed by ZScaler Intermediate Root CA, which clearly means it's been compromised. But if I go to, say, my bank, it says it's signed by Verisign. Am I right in thinking that means the bank connection has not been intercepted and is still end to end encrypted?
Zscaler allows the administrator to configure which sites/domains/categories will or will not be decrypted for inspection. It sounds like your admins have disabled SSL decryption sites in the finance category, and thus traffic to your bank is not being decrypted, whilst traffic to Facebook is.
As far as determining which traffic is and is not being decrypted you are exactly right - check the SSL certificate and if it's signed by the Zscaler certificate then the traffic is being Man-In-The-Middle'ed. If it's signed by any other certificate (including Verisign/etc) then it's NOT being MITM'ed.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
What I want to do is making my website available via https without getting these browser warning that the site is not trusted.
I created an SSL certificate for my domain and configured Apache webserver to use it in default-ssl. Calling my site with https:// works, but in every browser on every device a get the message that no issuer chain was provided. In firefox like:
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
What did I understand wrong with SSL?
The certificate you get is not directly signed by the Root-CA, but by an intermediate CA, which by itself got signed by the Root-CA. You have to add this intermediate CA to the certificates your server sends to the client, because the client only trusts the Root-CA and does not now the intermediate CA.
The process is described in various places, like https://eldon.me/?p=34
You say Startcom SSL - do you mean the free one? If so - that's a normal and import behavior of these browsers (well your free certificate isn't validated - no prove that this certificate really belongs to you). I actually hope there is no way around that.
Don't get me wrong - CA's have their advantages as well as disadvantages. What you could do for your users is take part in the web of trust, yet it won't help on that topic.
What you personally can do, is view the certificate (when the warning is displayed - don't directly click for a temporary exception) and then, there is an option to permanently save an exception for that certificate.
But you have to do that on every browser (once) and just works for you, every other user visiting the site has to do the same.
I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.