Default httpd.conf for WAF enables insecure Protocols/Suites (TLS1, TLS1.1, 3DES) and enables Trace/Track on each firmware update

Still struggling with this issue like AlanT was. 

Because i checked once again all my WAF XGs with TLS1.2 only, and it works fine with all my XGs without even change something in the config files at all. 

Used SSllabs to test my WAF. 

Also talked about this to some of my customers / partners. Nobody could relate to it. 

I assume, the config file / database got broken and rewrite all the time the "Use TLS1.0" back to your config. 

Can you post your (New) Sophos Support Case? So FloSupport can track it? 

PS: your screenshots are not readable. :) 

Sorry...copied the screen shots from the other thread and apparently they didn't size correctly.  I'll try to get them fixed.

As for a SSLLabs report with a non-edited httpd.conf file (I reset it) here are the results that I just ran (12/31/18 8:30 AM EST):

Again TLS 1.2 is enabled but it doesn't seem to care.  Only editing the httpd.conf file seems to fix this.  And my PCI compliance scans find the same thing so its not just them. Maybe I'll upgrade to 17.5 and see what happens if I don't hear anything back from AlanT in the near future.

This option is there since V17.0 GA. And it works for me and other customers. 

I am pretty sure, there is something broken in your config file (database). So the easy way to resolve this is: Update to the newest version ,set the flag to TLS1.2 and check, what is happening. If your WAF still uses TLS1.0, do not fix the config file, instead point to Support, this is broken, please fix it. 

Maybe you simply need to "resave" the configuration TLS1.2 and above and it will set the proper configuration. 

I did try switching it to TLS 1.0, hitting save, waiting a few minutes, and switching back to 1.2.  Didn't make a difference.  And here is the problem with updating to 17.5:  Another user has the exact same issue as me and upgrading to 17.5 did not fix the problem (See this post and then he reconfirms all the same issues in this post).  I can try updating but if it didn't work for him and hes had the same issues then I don't see how it will work for me.  But again I can try.  When it doesn't work (not a lot of faith at this point) hopefully support can do something other then tell me it should work.   Hate to be "insecure" waiting for support to fix it properly instead of just editing the config myself but if that's what I have to do I will.

Also the real question is AlanT said in the other thread that the https.conf shouldn't be used at all anymore but it obviously is.  I know that not only by the TLS 1.0/1.1 and 3DES being enabled but I also fail on HTTP Trace Back which I fix by also editing that file. 

I feel like I'm just repeating the same stuff over and over. There is obviously a bug.  Its not affecting only me.  I've contacted support who is telling me its not a bug and I just need to change a setting which I've already done.  The then say I need to upgrade which another user already did and it didn't fix anything.  How do I get my case up to a higher level that can actually figure out whats wrong?  Or how do I get the logs that I already sent over three weeks ago looked at?

To be honest, i do not know, what i going on on your appliance. And i am not an engineer to be sure and giving a proper answer about which config file is be used. 

They could be some kind of fallback, if you edit something by yourself on CLI. 

Which logs did you send? Because, to be honest again, XG Logs are sometimes quite large without the proper point to be sure, what is going on. You need to enable some debug modes to see, what is going on. I would not be able to tell you, what was the issue, if i can not enable debug logging and using some switches. 

 I still guess, if you are editing something in the file, it is not the proper way to do it. But to confirm this, i would have to simply debug the system live, while the issue is active. You could also demand to schedule a remote session with support. They would remotely support your while doing the update and checking the Logs after the update. 

That is just my two Cents.

First of all, lets make sure that AlanT sees this post.  Next, this is the holiday season so we should all be patient with replies.

Next, can I summarize the problem as I see it?

Michael Dunn - I agree with pretty much everything you said. 

However here are some questions.  In my original support case two years ago (case numbers above) this file apparently was used as your tech support people said it was and said I had to manually change it.  I'm assuming you can look up that case and verify this.  Since then I have had to do this for every firmware update, throughout 16.* and 17.*.  At what point did it stop getting used and reverse proxy take its place?  Could the fact mine was edited mess something up during a firmware update?  I doubt it based on you saying it gets overwritten each time.  Why would it even exist if its not used?

Or better yet how is my system still using it and how do I, and others with this issue, fix it.  JonathanP has the same issue on a XG450 that came pre-installed with 17 and exhibits the exact same issues.  He has since upgraded to 17.5 but it didn't help.

Whats the next step?

I've upgraded to 17.5 and the issue still happens.  I purchased the XG450 with 17.x pre-loaded.  I had to follow the steps for my XG450 to pass trustwave PCI scan. 

Hi AllanD,

Things change over the years and this is not my area of expertise.  Support sometimes also comes up with their own "solutions" which are really workarounds.  So I (myself) do not know exactly how it works nor when it changed.  I do not think that the fact you edited the file makes a difference, however I do suspect that there is something in your configuration causing this.  It might be a combination of features and configuration that can be done in WebAdmin, or it is a byproduct of a change that was made by you/support on the backend.

An example (and I'm not saying this is the issue, I'm just throwing darts) would be that XG uses the Zones (WAN, LAN, DMZ) to help control what traffic can flow in what direction.  If you somehow had a port in the LAN zone exposed and serving out your traffic on the WAN I could see that it could fail PCI scans.

If you turn off WAF completely, does this problem go away?  I presume that turning off WAF will make it so that no apache is listening anywhere on that external port, so there is no web access at all.  That would prove that WAF is the key part to this issue (which is only a presumption at this point).

AlanT knows more about this area than I, though he's actually a manager not a low level techie.  He knows the people who should know.  I'm not sure if he is back from winter holidays.  :)  You could send the configuration to me, but I can only do a cursory glance at him.  AFAIK you have sent it to Alan, and I think the next step is seeing what he says.

No, can't think of ever exposing any LAN ports out.  Plus again changing the config fixes it.

I can attempt to turn off WAF and rescan.  The issue with this is we host Outlook Anywhere, OMA, OWA, and a couple websites so they would be down during this time.  Also our PCI compliance scans usually take upward of a hour or so to complete.  I'll see if I can do it Sunday when usage is low.  Whats the easiest way to do this?  Disable all business application rules going to 80/443?

Agreed re LAN, but the underlying point is that sometimes configuration can have unintended consequences.  We've seen customers who create an ANY/ANY/ANY rule as a temporary workaround, and then forget about it and leave it in place for a year.  Ugh!

Did you also see this when doing the ssllabs.com scan?  That should be much quicker.

I would turn off all incoming business rules for 80/443, scan, and confirm that nothing comes through.

Then turn on a single rule (eg your "main" one) and scan again.  If it is still good, turn on more rules.  Maybe we hit the jackpot and find out that the problem is associated with a particular rule.

Yes, I posted a SSL Labs result above. It finds the exact same thing the PCI compliance scan finds. So you're right..... That would be much quicker.  I'll try that this Sunday and report back.  My feeling is it's any rule since I'm sure Jonathan's setup is different then mine but has the same issue.

We'll see.

Yes, I posted a SSL Labs result above. It finds the exact same thing the PCI compliance scan finds. So you're right..... That would be much quicker.  I'll try that this Sunday and report back.  My feeling is it's any rule since I'm sure Jonathan's setup is different then mine but has the same issue.

We'll see.