Why wiring things up physically instead of virtually is better for us
As I mentioned in my entry on the physical versus the virtual approach to network drop wiring, we use the physical wiring approach and I think it's the right approach for us. Today I want to run down my view of the collection of reasons that make it so.
First off is that physical wiring can be done almost entirely with a collection of inexpensive and relatively small switches, since most switches are only for a single VLAN. Virtual wiring basically demands big switches with a lot of ports so that you can handle as many drops as possible through one switch (both for bandwidth and for ease of management and configuration changes). Unfortunately our environment makes it hard to buy big, expensive things. It would be very hard for us to buy, upgrade, and replace the quite expensive (by our standards) core switch or switch stack that the virtual approach calls for.
A related advantage of the physical approach using lots of smaller switches is that we can mix and match switch types, picking the best (or cheapest) model and company for any particular purpose. We can also upgrade switches piece by piece, which is very much how our migration from 100 Mbit to 1 GBit Ethernet happened (and yes, it took years).
Next is a cluster of issues related to making wiring changes either physically or virtually:
- making switch configuration changes is not as easy as it looks, especially if you bought relatively inexpensive switches.
- for the switches we can afford, it's generally easier to see your actual
network configuration when it's embodied in physical wiring than when
it's all virtual. Colour-coding important networks helps in this.
- it's much easier to share access to wiring closets than it is to switch configurations, at least in our environment.
- it seems easier to train people to do physical wiring changes than it is to get them to do switch changes (especially if switch changes involve a complex dance to also make backups or mirror the changes on a backup switch).
- I think the chances of errors are lower in practice with physical wiring changes because of the physical nature of things. People can make slips in switch configuration that are much less likely when they are moving network wires (especially if they're only supposed to touch their switches).
I suspect but don't know for sure that our port-isolated networks would add complexity (and heartburn) in a giant-switch environment. It's possible that modern switches are smart enough that you can set this as a default VLAN parameter or something and have it work.
Good SSL for your website is absurdly difficult in practice
I failed. Which leads to this rant. In order to have good TLS on your website, here is what you need (in the abstract):
- You need to know what the current state of the art is in recommended
TLS settings and attacks, both for things to actively support
(such as perfect forward secrecy)
and things to avoid (RC4, TLS compression, and so on). All by
itself this is a minefield of outdated or contradictory advice.
- Your system's TLS libraries must support everything you want to do
(and sometimes your application software too). You also need to
know how to find out whether they do. This is far from guaranteed;
on Unix systems, your OpenSSL library may be too old or compiled
without patent-encumbered technology like elliptic curve
If good TLS settings require things your normal libraries don't
have you may have to build your own.
(Did you know that Fedora compiles OpenSSL without ECC? I didn't until I started reading deeply in this. Oh, and you may have to rebuild not just OpenSSL but also applications that depend on it, per this bug comment.)
- You must successfully translate those abstract good TLS settings
into actual concrete settings for your TLS libraries and application.
This primarily means controlling cipher choices through cipher
names. You also need to deal with the
fact that different clients support different ciphers so your job
is not just to specify a few really good ciphers but to come up
with a cipher ordering that prioritizes the good stuff, avoids
the bad stuff, works as best as possible for as many clients as
possible, and probably doesn't leave any clients in the cold.
Oh, and the available documentation for your TLS library is probably not very good and may not be complete. You also get to go through a three way translation process between full cipher names as reported in, eg, protocol decodes of actual client traffic, how you name and configure various sorts of ciphers in your TLS library, and the names that were used for ciphers in the abstract good TLS settings you've read up on.
Unless you're a real expert there is a lot of black magic and superstition in this process. You're taking guesses and hoping that they work right, which brings us to the next issue.
- Having come up with what you think is a good configuration, you need
to test it to see if it does what you think it does and gives
clients good results. In the process you may have to make decisions
about client support; for example, is it okay if IE 6 on Windows
XP probably can't connect to you? Is the testing you're doing
really covering the smartphone and tablet world?
There are testing sites but their results aren't necessarily complete and may require interpretation.
In the current environment you can apparently look forward to doing all of this all over again in six months when a new vulnerability gets discovered in another part of the TLS world.
Of course if you don't care about having top grade TLS support on your website, life is much easier; you can just accept the TLS defaults on your software. I'm not surprised that lots of people do just this because doing significantly better is a lot of work.
(You can also try following recipes that you found on the Internet. This may or may not actually work for you. If it doesn't work it may be because of something obscure in your specific environment, as it may have been for me until I discovered you have to recompile not just OpenSSL but lighttpd too in the process of writing this entry.)