• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Critical OpenSSL bug allows attackers to impersonate any trusted server

Scheduled Pinned Locked Moved OpenVPN
9 Posts 6 Posters 1.8k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N
    NOYB
    last edited by Jul 10, 2015, 8:45 AM

    Any implications here with OpenVPN?

    Critical OpenSSL bug allows attackers to impersonate any trusted server

    http://arstechnica.com/security/2015/07/critical-openssl-bug-allows-attackers-to-impersonate-any-trusted-server/

    1 Reply Last reply Reply Quote 0
    • S
      Supermule Banned
      last edited by Jul 10, 2015, 9:50 AM

      The good thing is that the way OpnSense is built its updates are quite frequent

      https://forum.opnsense.org/index.php?topic=944.0

      Allready getting patches later today.

      1 Reply Last reply Reply Quote 0
      • H
        heper
        last edited by Jul 10, 2015, 11:40 AM

        @ NOYB:

        @jimp:

        FreeBSD has fixes in, new snapshots of 2.2.4 will be out soon that have the problem corrected.

        https://www.freebsd.org/security/advisories/FreeBSD-SA-15:12.openssl.asc

        Actually upon closer examination, we aren't affected. The version in pfSense 2.2.x is before the affected feature was added. The fix in FreeBSD is only for 10-STABLE after a specific date.

        So no worries, folks. Just sit back and laugh at everyone else.

        @supermule  yes yes, we love you too …. bye

        1 Reply Last reply Reply Quote 0
        • S
          Supermule Banned
          last edited by Jul 10, 2015, 11:45 AM

          HAHAHAHAHAHAH :D

          Because the base layer is to old :D

          By the way. Allready patched and update released by the dev's @ OpnSense ;)

          1 Reply Last reply Reply Quote 0
          • J
            jimp Rebel Alliance Developer Netgate
            last edited by Jul 10, 2015, 12:50 PM

            @Supermule:

            HAHAHAHAHAHAH :D

            Because the base layer is to old :D

            By the way. Allready patched and update released by the dev's @ OpnSense ;)

            There is no "patch" for them to have received. Read the SA again and understand how FreeBSD patches OpenSSL. That update did zero for OpenSSL on opnsense, just like it would do zero for OpenSSL on pfSense. FreeBSD didn't patch OpenSSL on 10.1-RELEASE, only 10-STABLE after June.

            opnsense was never vulnerable, same as us, because FreeBSD doesn't upgrade the version of OpenSSL in a -RELEASE branch, it patches the flaws without upgrading the version. The 10.1-RELEASE errata/security branch does not get a version upgrade of OpenSSL, so it never had the affected features.

            So they did a lot of work for nothing if they rushed out a release.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • D
              dork.buttons
              last edited by Jul 10, 2015, 1:19 PM

              What's remarkable is that opnsense apparently did push out an update and at least one poster there claimed the patch fixed this issue with ssl.

              So, one possibility is that they didn't know if they were or were not vulnerable.  Another is that they're updating core crypto very quickly relative to the BSD release branh, and if so - why?  Updating ssl for the sake of updating ssl isn't something I want as part of firewall maintenance.

              I don't want my firewall to emulate my tablet, which runs cyanogen and offers me nightly updates.

              1 Reply Last reply Reply Quote 0
              • J
                jimp Rebel Alliance Developer Netgate
                last edited by Jul 10, 2015, 1:25 PM

                @dork.buttons:

                What's remarkable is that opnsense apparently did push out an update and at least one poster there claimed the patch fixed this issue with ssl.

                So, one possibility is that they didn't know if they were or were not vulnerable.  Another is that they're updating core crypto very quickly relative to the BSD release branh, and if so - why?  Updating ssl for the sake of updating ssl isn't something I want as part of firewall maintenance.

                I don't want my firewall to emulate my tablet, which runs cyanogen and offers me nightly updates.

                If they include a second version of OpenSSL (like we used to, but we stopped a while ago) then perhaps they have a second version around that was vulnerable. But the base system version of OpenSSL is "OpenSSL 1.0.1l-freebsd 15 Jan 2015" just like ours. Or maybe it affected their LibreSSL variant and not the other. I don't have a system handy at the moment to check.

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • J
                  jimp Rebel Alliance Developer Netgate
                  last edited by Jul 10, 2015, 2:34 PM

                  @jimp:

                  If they include a second version of OpenSSL (like we used to, but we stopped a while ago) then perhaps they have a second version around that was vulnerable. But the base system version of OpenSSL is "OpenSSL 1.0.1l-freebsd 15 Jan 2015" just like ours. Or maybe it affected their LibreSSL variant and not the other. I don't have a system handy at the moment to check.

                  So I was wrong, opnsense was affected. (pfSense still wasn't) It looks like opnsense did exactly as I posited above: They have a version of OpenSSL in /usr/local alongside the version in base, and it was affected, so they did need to update.

                  We stopped doing that a while back because of these sorts of headaches. It's safer and less confusing to keep only the base system OpenSSL and use it.

                  We had two copies around in 2.1.x because we needed OpenSSL 1.0.x for some things and it was tough to replace the 0.9.x version in the FreeBSD base back then, but for 2.2 we dropped the second version since it was no longer necessary.

                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by Jul 11, 2015, 5:40 AM Jul 11, 2015, 1:22 AM

                    @Supermule:

                    The good thing is that the way OpnSense is built its updates are quite frequent

                    https://forum.opnsense.org/index.php?topic=944.0

                    Allready getting patches later today.

                    Those "quite frequent" updates are easy when you don't do any testing. If it had applied, those who wanted a fix would have had one within an hour via 2.2.4 snapshots, with release soon to follow (still is coming soon, just not because of this) after it's been tested. But better off if you don't need patches at all because you aren't running two diff copies of OpenSSL unnecessarily.

                    1 Reply Last reply Reply Quote 0
                    9 out of 9
                    • First post
                      9/9
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                      This community forum collects and processes your personal information.
                      consent.not_received