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

This is a continuation of but a new thread was requested by LuCar Toni here:



On a fresh install of any firmware to a XG appliance the WAF settings allow insecure protocols and 3DES in addition to Trace/Track.  This has been a issue going back over two years (previous post: : )


Demonstration of what is happening.  After any firmware upgrade I have a PCI compliance scan done and get the following results:



I highlighted the failures on 3DES and TLS 1.0.  So I telnet in and check the appache httpd.conf file and this is whats in it:



Sure enough all those protocols are reenabled on each firmware upgrade.  I then manually edit that file to remove 3DES, TLSv1, TLSv1.1, and TraceTrack so it looks like this:



and restart the services (per instructions support gave me and I blogged about here). I then rescan and I no longer fail due to those items:



This is happening to multiple people on this forum and who have commented on my blog post.  Settings within the UI (mainly the "TLS setting") do not affect this behavior.


This is happening on 3 seperate XG boxes, one XG310 and a pair of XG125w.  All three were installed at different times and the last XG125W shipped with v17, the other two started with v16.  All three exhibit the same behavior on each firmware upgrade, the "secure" settings get wiped out and replaced by a "insecure set".

  • 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  can track it? 

    PS: your screenshots are not readable. :) 

  • Please build a new XG (using an older version) and then check the security settings.

    Then perform a restore of your configuration and check the security settings.

    Then allow the XG to install an update then check the security settings.

    Or build an new XG (older version), check the security settings, then run the update without your configuration.


  • In reply to rfcat_vk:

    I'm not sure how this would help as it doesn't appear to affect virtual machines and the only people that have reported it, myself, , and a couple people through my website, were all on appliances.  And I'm definitely not doing this to my XG310 which is in production....I'm not risking it breaking and our network being down.  Or are you saying start up a virtual machine and load the backup to it?  I can do that but again I don't think its going to matter.


    I'd rather wait for to let me know what he found after I send him the documentation he asked for a couple weeks ago.

  • In reply to LuCar Toni:

    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 in the near future.

  • In reply to AllanD:

    Again, you need a Support Case. I honestly believe, your XG is rewritting something all the time because something was changed back in the days in your Database configuration. 

    You could trigger the Support Case and giving the support all details, they need to check your log. 

  • In reply to LuCar Toni:

    I've entered a support case. Although I don't understand why I was asked for information if nothing is going to be done with it to try to solve this problem using it.  

    As for writting all the time Again it is only after a firmware update. Something in the firmware update is rewriting that file. From what @AlanT said the file shouldn't be used at all but it obviously is based on the evidence. If I manually edit the file and then I don't update firmware again for 6 months then the system is secure for that 6 months. As soon as I update the firmware it is no longer secure until I edit the file again.

  • In reply to AllanD:

    Do you use a HA? 

    You opened a Case before (back in the days), did the Sophos Support maybe changed something on your system? 

    I would say, there is something corrupt in your Backup file, which causes this behavior. That is my guess.


    I highly suggest to open a Case to follow the correct process for this issue.

  • In reply to LuCar Toni:

    I do not use HA.

    When I originally open the sport ticket, two years ago now, they said at the time the system didn't have an option for TLS 1.2 from the UI and that I needed to manually make the change through the councole. Which I did. I did nothing else other than follow their exact instructions to make the changes to httpd.conf.  and I have had to make the same changes with each firmware update since then. I'm not sure how that would be a corrupt backup file.

    And again I opened up a new support case, explain what was happening, and provided a link to this thread.

  • In reply to LuCar Toni:

    After some back and forth this is what Support said:

    "Version 17.5 GA has the settings for TLS version in WAF under General settings.  Kindly upgrade the device to latest version and after that if the issue persists then we can look into it further. "

    I told them that setting has already been changed, change back, and changed again with no effect.  I pointed them to this thread but haven't gotten anything back.  Were my logs I sent to  ever looked at?  Your support people don't seem to want to troubleshoot this until I upgrade but I shouldn't have to.  I am willing to upgrade if someone can tell me that the setting doesn't work prior to 17.5 but from what you and others have said it should.


    Old support case #7105754.  New support case # 8551864.   And here is a copy and paste from the old support case and what they told me to do:


    Hello Allan,

    I have heard back from GES on this issue.  They have provided a workaround for now, below are the instructions to disable TLSv1.0 for WAF.

    Workaround Solution :
    # mount -no remount,rw /
    # vi /usr/apache/conf/httpd.conf
    -- Edit the following two lines with the lines in red color. before editing create a backup of the original file:

    SSLProtocol all -SSLv2 -SSLv3

    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

    # service apache:restart -ds nosync
    #service WAF:restart -ds nosync
    #mount -no remount,ro /

    Please note this is only a workaround until the option to disable TLSv1.0 is included in the web admin of the XG. This will break an old legacy systems where DES and 3DES are the only supported ciphers "e.g. Windows XP clients or older versions of Windows Server.  This change will be overwritten by a software upgrade as well, every time you upgrade the firmware the workaround will need to be applied.

    GES has informed me that the option to disable TLSv1.0 will be added in SFOS v17.


    Sophos Technical Support


    Note the line that says this change will be overwritten by a software upgrade and need to be done each time?  That exactly what I've had to do for two years now.  Except changing the option in the UI doesn't fix it.

  • In reply to AllanD:

    Again, i am not a Support Engineer. I can only rephrase my experience with other customers. None of my customers could reproduce this since V17.0 

    All of them uses the Webadmin Option and it works fine. 

    I cannot tell you, what was done with your Log files. But the basic process is, to talk to the Support people about this issue to get some information. 

    There should be something wrong with your backup. You said back in the other Thread, you can reproduce this even after reinstalling your XG and restoring the config file, isnt it? 

  • In reply to LuCar Toni:

    I've never factory reset my XG and restored the backup, its on a production network and I don't really want to have to set it backup.  The problem is the httpd.conf gets reset with each firmware update to be insecure and it needs to be manually fixed.

    As for your support people they just sent a reply and said I should update to 17.5 GA and once I do there should be a TLS 1.2 option under Web server -> General that will fix this.  However that setting is already there and doesn't fix anything.  I've told them this twice and they just keep repling with the same thing:

    I have discussed this with my senior team and they have informed the same thing which I informed you. The version 17.5.0 GA has the feature to select the TLS version. You can manually set the TLS from there. TLS Version 1.2 you need to select and your issue with weak cipher should be resolved by selecting it.  After this selection when you upgrade the firmware further you should not be facing TLS version issue.

    This setting has been around since 17.1?  At least for the last couple versions I've upgraded to but again it is not doing anything. 

    Is there a bug fix that says 17.5 fixes this issue?  I haven't been able to find one.  I will upgrade if that's the fix but no one can tell me it is and I've already upgraded 10+ times with having to manually make the change each time.

  • In reply to AllanD:

    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. 


  • In reply to LuCar Toni:

    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?

  • In reply to AllanD:

    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.

  • In reply to LuCar Toni:

    First of all, lets make sure that 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?


    In a normal working brand new installed system:
    vi /usr/apache/conf/httpd.conf
    Looks like this:
    SSLProtocol all -SSLv2 -SSLv3
    This is normal.  The fact that this is reset to these values every update is normal.
    There are other files, such as the reverseproxy.conf that should take precedence over the httpd.conf.
    There is a problem in your system where the settings in httpd.conf are being used.
    The bug is not that /usr/apache/conf/httpd.conf has bad settings.
    The bug is that /usr/apache/conf/httpd.conf is being used.
    Therefore the premise that is in the thread title is incorrect.
    I do not think that backup, restore, factory reset, and upgrades are relevant.