Hacker News Reader

Comment by lloydatkinson | Hacker News Reader

I'm really stuck between deciding on which. opnsense claims it's concerned about code quality and separating logic from the UI. Sounds great (and means that pfSense must really suck in terms of code quality and security if they aren't doing that) but then following the link to the PHP framework they use you get:

> A full-stack PHP framework delivered as a C-extension!

I mean, I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.

View on HN

I can't really comment on the quality of the code, my reason for going opnsens over pfsense is mainly because the company that owns pfsense seem to be real asshats.

But, looking at: https://docs.opnsense.org/development/architecture.html It seems that it's mostly just the frontend that's php, or am I missing something?

Yes, I certainly feel much better now I read that thank you. I think I'll probably use opn then.

If it helps, about a year ago I was replacing a UniFi setup at home and I was trying to decide with pfSense or OPNsense. After poking at both in VMs for about a week I settled on OPNsese.

My main reasons were that it did everything I wanted pfSense to do, something about the UI felt a bit smoother to me, and it didn't have the smarmy/wonky feeling that pfSense does (aggressive company behavior, closed-ish stuff, and then post-switch the Wireguard stuff happened).

I'm running this on a Protectli FW4B and have been quite happy. It's still doing exactly what I wanted, updates have been good, a bug I reported got fixed quickly, and it's... just working.

Also, by going to open hardware (and not the Netgate stuff I was originally thinking of) I can switch to another platform (eg: Untangle, OpenBSD) if desired.

But, for the forseeable future, OPNsense seems to be working just fine. <shrug>

What moved you off of Unifi? Did you move off entirely, or just for the gateway?

I moved entirely. It was mostly the GW that I didn't like. The primary bug was when they changed the maximum SSID length from 32 (standard) to 31 and I could no longer edit my network.

I also had a very frustrating ARP bug where ARP broadcasts wouldn't work across mesh'd APs (https://www.reddit.com/r/UNIFI/comments/ghs4bg/arp_for_clien...).

Then there was just some various other quirkyness/weirdness, and I happened to get out just before the big security breach was disclosed.

I ended up going to a Ruckus R610 AP that I got via eBay running the Unleashed OS, and it's outstanding. Coverage is so good I no longer need my old AP + extra mesh'd one.

For switching I'm just using an old TP-Link that I had laying around.

UniFi seemed really neat at first, but then it just felt... overwraught. I don't need single-pane-of-glass monitoring of a ton of stuff for my home network. I don't want to run a management software server just for my home network. I do want something robust, but I don't want to worry about it, and I want to be able to piecemeal upgrade it. A small PC running OPNsense + a solid AP + just whatever for switching does exactly that.

(I'm not a homelab-type person... If I want that I use VMs, or my employer's hardware. I want my home network to be a solid, reliable utility that requires little maintenance. I don't want to be tweaking my home network after my day job.)

OPNSense replaced a lot of the old PHP that was in pfSense after it forked. So if PHP is a concern for you, you could argue that's OPNSense's PHP is better than pfSense's PHP.

OPNSense also splits front-end into the MVC and control layer, as well as the back-end between the control layer and the configuration daemon which is written in python.

All of the actual packet processing and daemons are C or C++, essentially the standard packages you'd find in FreeBSD.

Whether PHP or C is more secure depends on who wrote it.

I'm not a PHP programmer so I can't assess the quality of the code myself but do we know objectively that OPNSense's PHP is better than pfSense? That seems like a big assumption that just because it's been rewritten it's more secure or "better"

I do because I've worked with the code. It's not 100% beter or something like that, but the Phalcon framework does impose quality requirements to work with it effectively. It also has immutable facilities loaded as an extension (for speed benefit but also means you can't actually mess with the framework at runtime).

While I haven't really done any hardcode PHP work after PHP5 came out, there are plenty of ways to do it wrong, and a few ways to do it right. One thing is separation of concerns and encapsulation to the point where a fault in PHP can only mess up the PHP part and not the external system PHP calls into to ask for configuration changes.

Currently, a lot of the old pfSense code has been removed and replaced with code in the MVC framework, but it's a lot of work, and the team behind open-source OPNSense isn't huge. It will take time to cover it all.

>> A full-stack PHP framework delivered as a C-extension!

> I mean, I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.

What is inherently insecure about PHP? Or Phalcon? Do they have vulnerabilities that other C programs don't have?

PHP itself used to have a poor security track record. Not sure what the situation is these days? I guess this[1] is one place to start.

C programs are often exposed to classes of vulnerability owing to weaker safety guarantees see[2]

[1] https://wiki.php.net/cve

[2] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

Vulnerabilities in PHP appear regularly. A mass of them for PHP 7.x appeared in my inbox yesterday:

https://ubuntu.com/security/notices/USN-5006-1

I should think a quick google of "C string vulnerability" will answer your question.

Ah yes, the C users got triggered.

Yes, it's no Rust, but so what? You'll be dealing with a locked-down box in most/all situations, stuff won't be accessible to other than the sys admin (unless you misconfigure it).

> I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.

Phalcon was at one point moderately well-regarded, though it's fallen out of favor for a wide variety of reasons, mostly the PHP development style moving on. I say this because as near as I can tell, Phalcon has had an entire single CVE in its entire decade plus of active development.

Casual anti-PHP bigotry isn't just uninformed, its harmful.

PHP is already written in C and can be quite secure when following best practices (as with any language), so I'm not sure why an additional PHP extension written in C would be a red flag?

Note that Phalcon is a PHP extension (not a C extension) that provides new functionality available in the PHP runtime. This is roughly equivalent to a Ruby gem with a C extension, like Nokogiri.

Reply on news.ycombinator.com