Support tried valiantly, but was unable to help me figure out what's wrong.

All I want to do is create a fresh Linode (Ubuntu 14.04 LTS) with Apache and PHP to make outgoing SSL API calls (e.g. to LinkedIn). But I have to set it up so that SSL 2 and SSL 3 are turned off because of POODLE.

But no matter what I do, if I run https://www.poodlescan.com on the site I create it reports:

myhost.mydomain.com:443 (176.58.126.189) - Vulnerable
This server supports the SSL v3 protocol.
This server supports the SSL v2 protocol. You should really disable this protocol. It's WAY deprecated.

I've gone through all the "Getting Started" docs, and configured everything I can configure. Linode support, while trying to be helpful, asked for this and that command or config file output and they all look correct. But I can't get it to work.

They suggested somebody here in the forums can. I thought this would take me like 15 minutes to set up, and it's taken all day so far.

I can try to summarize the things I did.

1. I installed Apache and created a virtual server under it. I can place an index.html file in the public_html directory and see it from my browser, so that's working.

2. I set /etc/apache2/ports.conf to also listen to port 443.

3. I installed and enabled SSL and even created a self-signed cert in case that was needed (even though I'm just making outbound SSL POST requests). But even though I can get to http://myhost.mydomain.com I can't get to https://myhost.mydomain.com (even to get the self-signed cert warnings).

4. In both /etc/apache2/mods-available/ssl.conf and /etc/apache2/sites-available/default-ssl.conf I have

SSLProtocol All -SSLv2 -SSLv3

included. (I am not sure why both of those files need to be set though.)

Basically I'm confused.

Previously, if I did

service apache2 start

I was getting the error:

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443

Now I'm getting the message:

* Starting web server apache2

but no OK confirmation that it started.

I'm just basically confused at this point.

Any helpful hints out there?

Thanks,

doug

Reboot your Linode? Also pastebin your full apache configs and the domain name in question.

Also `apache2ctl -S`

- Les

Thanks for your reply.

I just tried rebooting, but that didn't help. The situation is still the same.

1. I can reach http://myhost.mydomain.com and see my index.html so I know the Apache server is running.

2. I can't reach https://myhost.mydomain.com, even to get a warning about it not being a trusted certificate. (This is not my goal, because all I want to be able to do is make outgoing secure POST requests to LinkedIn, but is indicative of the problem).

3. And https://www.poodlescan.com still reports the server is using both SSL3 and SSL2.

I tried the `apache2ctl -S` command and it reports:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 176.58.126.189. Set the 'ServerName' directive globally to suppress this message
VirtualHost: command not found

That first warning message appears a lot. I haven't tried to get rid of it yet except to see that ServerName is not the name of an existing command.

Anyway, it reports VirtualHost: command not found.

Any other ideas?

Thanks,

doug

You have not provided the information requested. You most likely have a configuration error.

Also, you should look at your error_log file for Apache to see what it says. It will report configuration errors in that when attempting to run. If there are errors, it will not run which sounds exactly what your problem is.

_________________
Kevin a.k.a. Dweeber

For starters, stop redacting your domain name.

If you're not serving an HTTPS site... what are you doing? Apache's SSL settings have absolutely nothing to do with your outbound HTTPS requests to somebody else's servers. You don't want or need to change anything in Apache's config for that.

If you're connecting to their system, you'd need to tell whatever you're using to do the connecting (PHP or whatever) not to use SSLv2 or v3 for the connection. That happens in your code, not in Apache.

You're getting weird errors from the scan and weird browser responses because you're serving HTTP on port 443:

❯ curl -I 'http://176.58.126.189:443'
HTTP/1.1 200 OK
Date: Thu, 08 Jan 2015 14:32:57 GMT
Server: Apache/2.4.7 (Ubuntu)
Connection: close
Content-Type: text/html;charset=UTF-8

Stop doing that, and you'll be fine.

Thanks for your message. The non-redacted full hostname is eldisodi.webcrossing.com.

I believe whether the server supports SSL3 is important because if it does then LinkedIn's API rejects connections from my server. My server at that point is acting like a client, and the client has to connect at TLS 1.0 or higher. If it support SSL3 then a fallback to SSL3 can occur because of the POODLE vulnerability.

LinkedIn (among others) is now rejecting SSL POST requests (e.g. to exchange an authentication code for an access token) if the request is coming from a server that supports SSL3, even if SSL is not turned on. I've been trying that for like two weeks now. You can read all about it in the LinkedIn blog for example. They say the only fix is to disable SSL3 on the server making the request, which is why I'm trying to set up a new server just to make these requests.

In their blog they wrote:

"In light of the recent disclosure of the "Poodle" SSL vulnerability, LinkedIn
is joining the large number of services that have actively removed support for
SSLv3, effective immediately. If you are experiencing errors related to
HTTPS-based communication with our APIs, please ensure you are using a
client/library that supports TLS 1.0+ instead of SSLv3 to avoid disruption."

and

"There is no fix for this issue. It is the result of an unfixable vulnerability
in the SSLv3 protocol itself, which is well outside of LinkedIn's control. We
will not be re-enabling support for this. You will have to use a library that
can make a different SSL connection."

I don't believe it's something I can specify in my request code. There is no header or anything for that. And everybody at LinkedIn and also stackoverflow insist the requesting server itself must disable SSL3.

In my case, since it is an outbound request, my server is acting like a client making a POST request. But because SSL3 is not disabled in my server the LinkedIn server refuses to handshake.

I'm serving ordinary http on port 80 I believe. If you go to http://eldisodi.webcrossing.com you can see the tiny test page there. That's on port 80, isn't it?

Thanks,

doug

What information requested have I not provided. Obviously I have an error somewhere. But I don't know how to figure out where. When I restart the Apache service there are no syntax errors reported.

Anyway, the error.log file for my virtual server is empty.

Where is there an error_log file?

Thanks,

doug

You are not listening. This issue has absolutely nothing to do with Apache. Revert the changes you made to Apache, because you're now serving HTTP on *both* 80 and 443, when you should not be serving HTTP on 443.

Apache is not at all involved, nor do LinkedIn's statements claim that it is. They claim correctly that whatever client or library you use to connect to their API needs to do so via TLS 1.0 or better. That client or library would be whichever PHP library, bash command, or other thing you are running to connect to their server. Whatever tool that is needs to know to use TLS 1.0+. That said, it's going to try TLS 1.0+ first if it can, and it cannot fall back to SSLv3 because LinkedIn does not allow connections via SSLv3. So if your tool is throwing errors, make sure it actually supports TLS at all.

Leave Apache alone, it has no connection to this issue. Pastebin the actual code you're hitting LinkedIn's server with and the error you get back from that attempt.

- Les

While I greatly appreciate your replies, please don't say I am not listening. All I have been doing is listening for 2 weeks now trying to solve this problem.

First I started with another server besides Apache these last two weeks, but that server could not disable SSL3 and that was the cause of the problem. That server did support TLS1 though.

I do understand that I cannot make an SSLv3 connection to LinkedIn. What I am saying is that all the LinkedIn developers have been telling me that because my server (prior to trying Apache today) ALSO supports SSLv3 in ADDITION to TLS1 that the connection is being refused.

What can I say? I've round and round this point for 2 weeks over at StackOverflow, and that's what all the LinkedIn API developers insist is the case. The calling server, they say, must NOT support SSL3 even if it supports TLS 1.

So that's why I created this new Apache server today - so I would have a server free of SSL 3.

But if I go to a site like poodlescan it says SSL3 is enabled on the server.

I'm willing to start from zero again and wipe out Apache and do whatever is necessary. But from what I've heard from expert LinkedIn API people these last couple of weeks I do think the server has to be set to completely disable SSL3.

Right now my settings are so confused I don't know what to do anymore though.

But please don't again say "I'm not listening." It's a personal characterization that's not fair. I've been listening and trying everything people have been suggesting for 2 weeks now.

Thanks,

doug

One more point - I can't pastebin in the code I've been using to hit LinkedIn with because I haven't rewritten it into PHP yet. It is currently written in server-side JavaScript for my other server, which is a non-LAMP server.

doug

I'm telling you you're wrong. The thing that matters is SSL/TLS support in the code that actually makes requests at their API. Other servers running on the same system don't matter.

The scan says your Apache is affected because you're serving HTTP on port 443 and that's confusing the heck out of it.

The web server does not matter. It is not relevant. Stop messing with it.

Your code / client libraries are the issue. If they're in Javascript, paste the javascript. The issue here is with that, not with unrelated web servers.

- Les

Telling me I am wrong is something I can accept.

Obviously I'm doing something wrong.

But I will tell you this for sure: The server I was previously using supported at least TLS 1.0. And LinkedIn was rejecting my SSL POST calls because it detected an SSL 3 on my side.

Let's forget the JavaScript I am using at the other server because it is server-side JavaScript, not client-side JavaScript, and is not in widespread use, and won't run under Apache, so it won't help to post it here. But the contents of the POST request were correct and I could make the same POST request from that server to other servers and get a response with the data I sent, so I know the POST headers and body were correctly formed. I'm going to be translating it into equivalent PHP anyway (my entire purpose for setting up the new Linode today) and if I run into a problem with that I'll post about it.

So please let me ask you this, if you don't mind. I just removed Listening 443 from ports.conf and ran "a2dismod ssl" to turn off SSL (it reported that SSL was already disabled, which surprised me because following the Linode documentation I had earlier enabled it with a2enmod ssl and created a self-signed certificate. But anyway.). And I restarted the Apache service.

poodlescan is still reporting

Scan results
eldisodi.webcrossing.com:443 (176.58.126.189) - Vulnerable
This server supports the SSL v3 protocol.
This server supports the SSL v2 protocol. You should really disable this protocol. It's WAY deprecated.

According to your scan do you still see me serving HTTP on port 443? If so, can you suggest a way of turning that off. The only "443" I edited anywhere was the Listening line in ports.conf.

Thanks,

doug

I'm not going to help further if you aren't going to read what I'm saying.

Turn off Apache, it's not relevant here at all. Paste whatever code you're running that's talking to LinkedIn's API and the error it's returning.

- Les

I have to admit I'm shocked by your response and that you continue to say I'm "not reading what you are saying." Didn't I just try to rewind and turn off the listening on port 443 as you suggested? I was trying to be agreeable and forget about SSL and port 443 and try it your way!!! So I can't fathom why you wrote what you just wrote.

The error that LinkedIn API's returned was a failure to negotiate SSL 3. But since it is now you who are not reading what I'm saying you are probably right that we stop the conversation.

Is there anybody willing to try to help? I am willing to try any settings suggested. I really am.

And how can I use PHP without Apache? Sigh.

Thanks,

doug

Hmmmm...

The warning you saw on the blog was just that it has NOTHING to do with your Apache Web server or it's configuration.

Read the warning you posted before:



Note it is talking about your CLIENT. That is what you are using to talk to them. Your Apache web server does not make connections to them, it receives connections to visitors to YOU.

So whatever software you are using to communicate to their API is what you should be looking at.

The issues with your Apache web server are completely separate from that issue and has nothing to do with what you are reading about the API you are attempting to connect to. If you are also having Apache issues, that is a different subject and has nothing to do with connecting to their API.

You have not provided as far as I can see any info on the CLIENT you are using to communicate to their API.



Yes.

_________________
Kevin a.k.a. Dweeber