We Can Not Get The SSL To Work
-
Hello,
Recently an outside vendor came in to do a demo of their product. Their product (which is another product rebranded) has the amazing ability to monitor and access computers remotely. It is a system administration tool useful to Windows admins. This futuristic tool allows a system admin to access an end users desktop remotely using an ASP application. You can access hundreds of businesses machines via a web browser.
Why the vendor was giving the demo of their product I noticed that they were not using SSL to encrypt their communication from the web browser to the centralized web server that allowed remote access to thousands of Window boxes. When I brought this to the attention of CTO of the unamed vendor their response was "We can not get the SSL to work because of an update that occured with our Windows 2003 Server".
This company provides technical support to Windows desktops and servers. How could a company offer security analysis and penetration testing and not be capable of getting SSL working?
Please see some of my prior posts for more backstory.
Unforturtunately, they will be integrating with my company :( Good news is I use Linux and their product does not work with Linux. Maybe I can get it to run under Wine :)
-
@OSvsOS said:
Certificate Services. The idiots don't know that this needs to be set up for SSL to work, it seems.This company provides technical support to Windows desktops and servers. How could a company offer security analysis and penetration testing and not be capable of getting SSL working?
I stumbled on this when using an LDAP client to add users into Active Directory. It required an SSL/TLS connection ... and to enable SSL, I needed to install Certificate Services. Oh, and it creates its own CA and internal certs for that as well.
-
I wonder if I can perform the fix for an enormous fee :)
@danixdefcon5 said:
Certificate Services. The idiots don't know that this needs to be set up for SSL to work, it seems.
I stumbled on this when using an LDAP client to add users into Active Directory. It required an SSL/TLS connection ... and to enable SSL, I needed to install Certificate Services. Oh, and it creates its own CA and internal certs for that as well.
-
Uh. ASP aplication, Windows 2003 server. They're running IIS. You type a port number in the configuration box, go over to whatever that tab is named, click "Server certificate" or summat like that, and GIVE IT A BLOODY FUCKING CERTIFICATE.
It. Is. Not. Hard. (Unless you've gone and "tweaked" your OS install for "speed" by removing "unnecessary services" - people who do such things for security purposes generally know enough to avoid disabling security services that they need)
-
In IIS 6 RTM, you couldn't bind SSL certificates to multiple sites that were differentiated only by host header - the sites had to be on different IP addresses otherwise you would get error messages in the event log and only one of the sites would start.
They corrected this in 2003 SP1, but IIS Manager still doesn't let you do it. You have to use adsutil.vbs to configure SSL bindings, and you have to use a wildcard cert.
Perhaps this is the problem, it's a little obscure but when we ran into this issue a little Googling had it resolved fairly quickly.
-
Apparently IIS Manager is fixed now, because I very much do have a pair of SSL sites running and bound to the same IP.
I did run into a problem where it refused to let me use standard-ish-HTTP port numbers (80, 81, 88, 8080, 8888) for one of the SSL sites, but fixed that by using some absurd ephemeral-range number instead.
Unless I've hallucinated this entire clusterfuck of a project (please let that be it! please let this all be a huge acid trip!)
-
@Weng said:
Apparently IIS Manager is fixed now, because I very much do have a pair of SSL sites running and bound to the same IP.
I did run into a problem where it refused to let me use standard-ish-HTTP port numbers (80, 81, 88, 8080, 8888) for one of the SSL sites, but fixed that by using some absurd ephemeral-range number instead.
Unless I've hallucinated this entire clusterfuck of a project (please let that be it! please let this all be a huge acid trip!)
I think he meant that IIS Manager does not let you bind multiple sites to the same IP and port: it can only be done with the external script.
-
I think there's a very good reason why it doesn't let you do that... How would that even WORK!? I send an HTTP request to a given IP on a given port and... How the fuck does it know what to send back? I'm not aware of an HTTP status "HTTP 5xx Idiotic Admin" - though they do have "HTTP 418 - I'm a teapot"
-
Upon rereading, I'm an idiot. He's talking about differentiating by header (which IMO is stupid and overly complicated, but if some bigwig asshat is going to cry blood over a port number appearing in his URL, okay. Fine. Make life more complicated if it pays the bills)
-
You can not do vhosting on with ssl and multiple sites on the same port at the same time. It is a fundamental flaw in the ssl protocol.
-
@Weng said:
Think about how many different websites there are. Now think about how many different IPv4 addresses there are and how many of those can be used by webhosting companies. This is why name-based vhosts exist.Upon rereading, I'm an idiot. He's talking about differentiating by header (which IMO is stupid and overly complicated, but if some bigwig asshat is going to cry blood over a port number appearing in his URL, okay. Fine. Make life more complicated if it pays the bills)
I guess the problem with SSL is that secure communications are engaged and the certificate transferred before any HTTP headers are sent to the server, thus there may be only one certificate for each addr:port pair. And since browsers like to validate (and with good reason) that the certificate belongs to the site they think it does, that means only one site per such pair.
A lot of people most certainly are going to cry if a port number appears in their web address. I would. How would you like to be reachable through http://www.yourcompany.com:16385/? Easy to remember, eh? If you accidentally mistype a digit, you end up at a completely different company's website. And if you ever change to another webhosting company, the port number's very likely to change, invalidating all existing links to your website. I guess a workaround could be that each webhosting company would have a frontend service running at the default port that would look at the host header, look up the port and issue the correct redirect response. But that wouldn't be all that much different from host-based vhosts.
-
@Weng said:
WTF? Differentiating returned content based on the Host: header is one of the most fundamental mechanisms of HTTP/1.1 and the standard way of implementing vhosts, or so I thought?Upon rereading, I'm an idiot. He's talking about differentiating by header (which IMO is stupid and overly complicated
-
@tdb said:
I guess the problem with SSL is that secure communications are engaged and the certificate transferred before any HTTP headers are sent to the server, thus there may be only one certificate for each addr:port pair. And since browsers like to validate (and with good reason) that the certificate belongs to the site they think it does, that means only one site per such pair.
RFC 2817 is a proposed standard to fix this problem, by connecting on the standard port, and upgrading to use TLS (rather than using SSL on an alternate port). Unfortunately, I don't think any common web browsers (and possibly not servers) support it yet, which is a shame because it seems to be a much better designed system than the current 'https://' system which just 'happened'.
-
@Weng said:
...though they do have "HTTP 418 - I'm a teapot"
I wasn't aware we were discussing HTCPCP.
-
@DaveK said:
Did you read this post?@Weng said:
WTF? Differentiating returned content based on the Host: header is one of the most fundamental mechanisms of HTTP/1.1 and the standard way of implementing vhosts, or so I thought?Upon rereading, I'm an idiot. He's talking about differentiating by header (which IMO is stupid and overly complicated
@henke37 said:
You can not do vhosting on with ssl and multiple sites on the same port at the same time. It is a fundamental flaw in the ssl protocol.
It's impossible to apply the HTTP/1.1 Host: solution because the cert is used to start the SSL connection. So the Host: header is sent after SSL handshaking has occurred and the cert already sent.I found out about this flaw very quickly... while I still was in college.
The case in point I think was for certs working in the same IP (but not necessarily the same port) but different CN being rejected.
-
@danixdefcon5 said:
It's impossible to apply the HTTP/1.1 Host: solution because the cert is used to start the SSL connection. So the Host: header is sent after SSL handshaking has occurred and the cert already sent.
I found out about this flaw very quickly... while I still was in college.
The case in point I think was for certs working in the same IP (but not necessarily the same port) but different CN being rejected.
Correct, but there is a proposed fix to this which was mentioned earlier in the thread, which relies on functionality much like SMTPS with unencrypted traffic until a STARTTLS command is issued, at which point TLS negotiation occurs, with the hostname already known to the server.
-
@henke37 said:
You can not do vhosting on with ssl and multiple sites on the same port at the same time. It is a fundamental flaw in the ssl protocol.
Yes you can, you just need all of the hostnames to be in the cert or else the browser will bitch about the cert not being valid for the FQDN.
