From my back yard -- literally..... the bridge is visible out my back door.

Vest says it is a cold hard fact that tolls on the Mid-Bay Bridge will not increase to $7.50 next year. It is likewise written in stone, he said, that there will be no bridge toll hike of any amount before Oct. 1, 2015, the beginning of the 2016 fiscal year.

....

In fact, the Mid-Bay Bridge, built with $81 million in bonds in the early 1990s, these days carries a debt load of $260 million.

That’s why it is possible, Vest concedes, that if the Bridge Authority does find it needs to raise tolls for the third time in its existence, the cost of the trip across could go from $3 to $4 for two-axle vehicles and $2 to $3 for SunPass holders.

Nobody is talking about how the bridge went from $81 million in bonds to $260 million outstanding.

Nor are they talking about the "fact" that the terms of the bonds dictate that tolls must (if necessary) rise.

Even if doing so cuts use, and thus the total revenue falls, producing a death spiral.

Which, incidentally, has happened already not so far away (Garcon Point anyone?)

The problem with these projects is that they invariably obtain their "go ahead" from the local residents predicated on two promises -- first, that they will be built and operated on time and on budget, and second that the bonds will be retired and once they have been the tolls will be lifted or reduced to that which is necessary only for ongoing maintenance.

The latter never happens and the former almost-never does.

The people responsible for that gross dereliction of duty, resulting in the tripling of the bridge's debt, from the County Commissions on to these "authorities", never, ever face prosecution or even debarment from public office for the outrageous deception they run on local residents in the promises they make and never keep when it comes to these "projects."  Never mind that if I screwed someone in the private sector to this degree I would, and the Commissioners and Authority "trustees" should, find themselves on the wrong end of a felony conviction.

But see, political promises carry no weight and are utterly unenforceable even when they screw the taxpayer blind.  As a politician you can make claims that you have absolutely no rational backing for or even lie outright and when your "projections" and "expectations" turn out to be crap nothing happens to you for buying votes with what proves up to be a pipe dream or worse.

Instead of being accountable these very same public officials now make excuses and tell us how "wonderful" the cut of 20 minutes will be on our mythical trip that they dream will fill the coffers and pay the coupon on said unsustainable and outrageous debt -- debt that their outrageously unrealistic expectations and projections caused to triple from what was originally proposed and agreed to by the people in the first place.

The "add-on" extension now being constructed is responsible for $143 million of this debt.  But there is no evidence -- absolutely zero in fact, even based on the rosiest of projections -- that the bond issues outstanding will be retired on or before the roadway requires resurfacing.

Indeed, had there been any record of the Authority being able to pay down debt predicated on operating revenue the problem, and debt, wouldn't exist -- right?

The inevitable resurfacing and upkeep in coming years will be yet another expensive act that will in turn requiring issuing even more debt.

This is a "tiny" little ponzi scheme in the grand litany of lies and scams promulgated by County Commissions and "local authorities" of all sorts, from these feifdoms to school boards, all over the land, backed up by bond issuers at banks who "help float" debt that mathematically cannot be retired on or before additional capital expense in maintenance and repair becomes necessary.

The banks, for their part, don't give a damn provided they get their fee.  The accuracy of their projections for sustainability and paydown of the debt issued, just like everyone else's, are never coupled to accountability.

Indeed I'm willing to bet that under any reasonable estimate of actual historical use and toll collection, less operating expense (salaries of the toll collectors, routine maintenance and inspections, etc) the bond issues can never be retired when the imputed operating costs, including resurfacing and other work on the expected intervals, is taken into account.

Those in the "authority" and County Commission who think that traffic will rise to meet the required revenue are flat out of their minds.

The fact of the matter is that ramping toll costs over the last years have already prompted WalMart and Publix to build stores on this side of the bridge.  WalMart is open now and Publix will be soon; the earth-moving equipment is in daily operation on that project right now.

That has and will continue to reduce, dramatically so, the "need" for local residents to cross said bridge and thus reduce the number of trips -- and the tolls collected.

The market has and will continue to spit in the face of the Okaloosa County Commission and MidBay Bridge Authority, reducing their pipe dreams of "efficiency in transportation" (not to mention their delusions of grandeur) to ash.

The market, of course, has a long history of doing exactly this quite efficiently; as price rises the utility value ex-cost to the local residents decreases.  That increased net cost in turn causes businesses to find a reason to make it easier, faster and cheaper for residents to avoid paying said price.

Oh sure, the theory goes, the county can rape the tourists, right after they spend $5 million in advertising to herd them in on their vacation so they can get bent over the fish-cleaning table while their wallet is vacuumed out.  And let's not kid ourselves -- for those tourists who don't have a SunPass (that would be nearly all of them) when they get surprised by the all-automatic plaza on the extension and are forced to pay $11.50 (which will show up in the mail when they get home) that is likely to have a rather serious impact on their view of this area -- and not in a good way either.

But heh, the MidBay Bridge Authority will cackle at their playing of the proverbial troll.

The question is whether said tourists will come back to be screwed again, and if not, what happens to those precious "bonds" and their demanded coupon.

PS: The rolling of that debt, historically thus far, has been made possible only due to the secular decline in interest rates over the last 30 years.  That secular decline is now over which means that all such projects that cannot retire their debt from operating revenue before it comes due are inevitably going to blow up in the coming years and decades.  This is a mathematical certainty Mr. Vest.

The first paragraph reads:

In a big day for gay-rights advocates, the Supreme Court on Wednesday struck down a federal provision denying benefits to legally married gay couples and issued a separate ruling that paves the way for same-sex marriages to resume in California.

Well, yes, but don't get to the partying just yet.

See, The Federal Government has no right to enter your bedroom and dictate to you what constitutes a marriage in the first place.  Neither do State governments.  Both arrogated to themselves powers they did not have and which, at least in the Federal case, violate the 1st Amendment.

Marriage is a religious institution.  It always has been.  It predates our modern governments.  In the early days of what was to become the United States, and through the lands before, you posted your Banns of Marriage on the church door.  The only "involvement" the government had historically was in organized bigotry -- that is, making damn sure you didn't marry a Lord if you were a commoner.

That translated directly to the United States; the original marriage "laws" were for the explicit purpose of making sure you didn't marry a white person if you were black, or an American Indian if you weren't one yourself.  

Think I'm kidding?  I'm not -- go look it up.

So what you, dear readers who support this, gay or straight, have bought into is turning what is supposed to be about two individuals who love one another into a tri-party deal with the State -- the damned government -- in the middle of your relationship.  

You cheered this today.

You fools.

You were baited by the siren song of that which you could easily have without any such crap.  Powers of Attorney work just fine for medical and financial decisions and cost nothing to draw up.  They're superior to the default "rules" too, because you can craft exactly what you -- and your partner -- want.

Wills, trusts, estate planning, all fairly simple and all doable unless you're terribly rich, in which case the passage of an estate from one "married" partner to another is in fact easier.  But most of you reading this don't have a pot to piss in when it comes to your estate anyway or are well under the limits where it matters.  Never mind that, once again, most of the time the default isn't exactly what you want, so again you've saved exactly nothing.

Access to "health insurance"?  Really?  ObamaCare has already destroyed what you thought you were going to get.  Welcome to reality.  Never mind that creating a monster and then using it as justification for a second stupid thing qualifies as Darwin Award material.  In this case given what ObamaCare is bringing to you that's not a rhetorical observation either.

The truth is that it's none of anyone's damn business who I choose to take up with, so long as we're both consenting adults.  The same applies to you.

If you have heart-felt beliefs about what marriage means to you in a religious context you need to have a very long session with your conscience, because it is a virtual certainty that you lied before God when you took that oath.  You presented a paper to a Minister, Priest, or Rabbi from a government that is a legally-binding document giving the government the right to define what your marriage was at the time, change it without your consent in the future, and define the terms under which you may modify or end it.  You did this contemporary with taking your oath "Before God" and then after you took that oath you pissed all over it as your officiant signed that piece of government paper post oath and sent it in to be registered.

Now we have gay people dancing in the streets over the right to lie to their creator, or whoever they choose to officiate their ceremony.  Unless, of course, it's a Judge -- then it's all ok.  We have taken all context from the word marriage that resides beyond letting the government literally into your bedroom to share your most-intimate moments, defining what is and is not legitimate, how you will love and just as importantly how you will end your time together if and when that love ends.

The worst part of it is that you can't even hold the government to the rules they have at the time you get married.  They change literally on a daily basis like Calvinball and once you submit to this jackbooted crap you have no ability to argue for application of the law at the time you entered into the agreement; you are bound instead by whatever government decides to do later on, even decades later on, irrespective of how either of you feel about it.

Your life no longer belongs to you and your paramour; you both cede all control over your most-intimate moments and, if necessary, their resolution.

The solution to the problem faced by gay people was never to be found in government interference; rather, it was to remove government from the bedrooms of our nation in their entirety.  To return marriage, such as it is, to a private contractual matter between two persons and, if they choose, a religious officiant that matches their desire.  To be able to form actual contracts that must be mutually renegotiated -- or terminated -- in accordance with what the people who entered into them agreed to at the time, not retroactively determined by some robed jackass who is free to change whatever you agree to 10, 20, 30 or more years ago to suit his beliefs, expectations and whatever government decides at any point -- without and even explicitly against your mutual consent.

Gay people didn't win anything today.  They, like so many who argue for both "contemporary" and "traditional" marriage, instead lost yet another battle in the fight for soul of both our nation and her people.  

I hope you enjoy having the government under the sheets with you.  

It's what all of you dancing in the streets are celebrating this evening, whether you realize it or not.

Now we're seeing some reality from a few folks who have avoided it for quite some time...

Facebook Inc. (FB) plans to bolster efforts to keep hate speech off its pages amid complaints the site allowed content that encouraged violence against women, prompting companies to suspend advertisements.

Nissan Motor Co.’s U.K. unit and lender Nationwide Building Society halted some Facebook ads that could have appeared next to offensive content after the group Women, Action, & the Media criticized the social network’s response to complaints. Menlo Park, California-based Facebook said it will review guidelines for evaluating content that may violate its standards, and will update training for teams that review reports on hate speech.

The problem is defining "hate speech", of course, and how this meshes with corporate advertising.

Bloomberg properly identifies the issue, which is that "good taste" may turn off advertisers.  But of course Bloomberg, like all people who have a vested interest in turning you into sheep, calls bad taste "hate speech", evading the issue at hand by branding it with a phrase intended to disparge.

The real problem is that association of an advertised product with something the advertiser disapproves of tends to lead them to stop paying for said ads!

That, in turn, has a habit of leading users of services like Facebook to ask what are we here?

The answer, as I have repeatedly pointed out, is "product"

This is not going to end well for firms that have promoted themselves to users as some sort of bastion of free speech and "expression" when in fact the reason they exist and have put together their "business" is to obtain product in the form of users who are then marketed to Madison Avenue!

This is the soft underbelly of the "new media"; media costs money to run, of course -- computers, bandwidth and electricity all cost money.  Somehow the money has to come in to cover the cost, along with the development of the software you use.  When you offer something to people for "free" the fact of the matter is that there is no such thing as "free" -- you just don't see the cost directly.

"Social Media" is the worst in this regard in that you are the product, not the company's service.  And while posting cute pictures of your cat is unlikely to offend anyone (and thus is "valuable" if they're really cute pictures) think about what's going on here -- you are providing creative input for free to the social media site who then sells YOU to Madison Avenue and makes money off your cat.

The cat doesn't care and you probably don't either, because you get to "communicate" (really?)

But -- what happens when you post pictures of the outcome of war?  A poor bastard who had his legs blown off in a bombing?  Perhaps it's a picture of some random person blowing chunks all over the wall at a local party.  Is that "hate speech"?

Budweiser probably doesn't want their beer associated with the latter; after all, Bud is to be associated with "happy times" such as sporting events and grand backyard parties, right?

That is, Budweiser hates that picture of the chunk-blowing -- which for them, makes that picture "hate speech."

You, on the other hand, probably think your photos of the beer bong contest (and its outcome) are hilarious.

Yep.

Very few people understand that Facebook is not a "right" nor are they "customers."  They are in fact product and like all product, if the store owner determines that it looks off-color or smells like long-dead fish you're going to find yourself tossed in the dumpster.

The question is whether, once those "off color" products are ejected, what remains is sufficiently interesting to the buyers (Madison Avenue) to constitute a successful marketplace.

I still believe the answer to that, in the case of Facebook and most other "social media", is no.

I keep getting poked on this on and off and it's a real problem.

Cell carriers use "deep packet inspection" to detect people cheating on their tethering plans (they want you to pay, see) and "bust" you if you do so but don't pay them.  They'd never look at anything else -- or for other purposes -- right?

You walk into a Starbucks or other place with "Free" WiFi.  Never mind the store, the connection is unsecured which means anyone within 300' or so of you can see everything that goes over the link during that time using trivially-available software and an ordinary PC or cellphone with a WiFi connection.  Nobody would ever do that, right?

You're in your hotel room.  You log into some web site and surf around.  Nobody else in the same hotel is monitoring that free, unsecured WiFi -- right?

Uh, yeah.

If you have a machine at home (or your office) that is on all the time and provides a firewall and NAT service for computers behind it, and you both can (and should), you might want to read this article.

I will assume you have such a machine.  It could be running either Linux or FreeBSD.  I will also assume that you want an actual secure VPN connection.  There are tutorials all over the place on less-secure options such as PPTP and LT2P; these work, but have potential points of attack that may be serious trouble.  Note that they're ok for casual use and will stop most of the garden-variety hackers, and certainly are better than nothing!

But today we're going to talk about setting up an IPSEC/IKEv2 gateway, and we're going to do it on FreeBSD.  We'll set it up for two environments -- Windows 7 machines (8 should also work) and the new BlackBerry BB10 phones (Z-10, Q-10, etc) along with, if you wish, the Playbook.

If you do this you're putting in place no-BS high-grade secure communications, at least as far as your device and your network.  This doesn't stop someone from physically breaking into your home (or hacking your gateway) but it sure as hell does stop any sort of casual (or not-so-casual!) interception of what you're sending and receiving from a mobile device where you and the device are.

The first thing to get is of course the FreeBSD machine and configure it with a firewall and in-kernel NAT.  Linux also works for this, incidentally, although the steps are a bit different.  I'm a FreeBSD guy so I'm doing it on that as a base.

FreeBSD requires that you add the IPSEC extensions to the kernel and recompile it.  That has to be done first; the options you need in the kernel are:

options IPSEC
options IPSEC_NAT_T
device crypto
options IPSEC_FILTERTUNNEL

(If you don't know how to build and install a custom kernel see The Handbook for instructions)

The next thing we're going to do is edit our firewall.  Your configuration will differ but the important point is that you will have packets coming in on a private address but on the external interface.  Most firewall configurations will reject this.  My setup has the following changes in it:

#
# Permit IPSEC VPN to operate
#
${fwcmd} add 1500 pass udp from any to any isakmp keep-state
${fwcmd} add 1510 pass udp from any isakmp to any keep-state
${fwcmd} add 1520 pass udp from any to any 4500 keep-state
${fwcmd} add 1530 pass udp from any 4500 to any keep-state
${fwcmd} add 1540 pass esp from any to any
${fwcmd} add 1550 pass ah from any to any
${fwcmd} add 1560 pass ipencap from any to any

# Network Address Translation. This rule is placed here deliberately
# so that it does not interfere with the surrounding address-checking
# rules. If for example one of your internal LAN machines had its IP
# address set to 192.0.2.1 then an incoming packet for it after being
# translated by natd(8) would match the `deny' rule above. Similarly
# an outgoing packet originated from it before being translated would
# match the `deny' rule below.

case ${firewall_nat_enable} in
[Yy][Ee][Ss])
if [ -n "${nat_interface}" ]; then
${fwcmd} nat 1 config ip 70.169.168.7 log
# ${fwcmd} nat 1 config if ${nat_interface} log reset
${fwcmd} add 2000 nat 1 ip from any to any via ${nat_interface}
${fwcmd} add 2010 nat 1 ip from any to any from ${nat_interface} ipsec
fi
;;
esac

# Stop RFC1918 nets on the outside interface
${fwcmd} add 3000 deny log all from 10.0.0.0/8 to any via ${oif} not ipsec
${fwcmd} add 3010 deny log all from 172.16.0.0/12 to any via ${oif} not ipsec
${fwcmd} add 3020 deny log all from 192.168.0.0/16 to any recv ${oif} not ipsec
#
# It's ok for IKE traffic to head from here
#
${fwcmd} add 4000 pass ip from any to 192.168.0.0/16 via ${oif}

What I'm doing here is telling the system first that the packet types that are intended for IPSEC are allowed to pass unmolested into the IPSEC subsystem (the top block.)  I then tell the system that I must NAT anything coming in from the IPSEC system, and finally I exempt anything from the IPSEC stack from the anti-spoofing filter just underneath it.  Your configuration here will vary, especially if you're using pf or Linux.  Adjust to suit your requirements.

The next thing to do is download StrongSwan.  The current release is 5.0.4 although there is a port in for FreeBSD that is also available (5.0.1) that will also work.  I recommend compiling up 5.0.4 because you want some options that may not be in the port; the string you type to "configure" to get the correct settings to allow Windows 7 clients (which is where the tricky part comes from) is:

$ ./configure --enable-kernel-pfkey --enable-kernel-pfroute --disable-kernel-netlink --disable-tools --disable-scripts --with-group=wheel --enable-eap-gtc --enable-xauth-pam --enable-eap-mschapv2 --enable-md4 --enable-eap-identity

Yes, that's long.  Just copy it over and use it.  Then type "make" and assuming it builds, "make install" (the latter as root.)  Now you have the software on the machine.

The next thing we need to do is set up certificates.  Let me explain.

There are two ways to secure a link, basically.  The first is a password.  But there is a problem with passwords, in that somehow you have to get them from one end of the connection to the other.  If the person who is trying to screw you can intercept that they can steal the password and now you're in trouble.

Certificates get around this problem and are the basis for "https:" connections and similar.  There are two parts to a certificate -- a public key and a private key.  The concept is that what you encrypt or sign with one you can only decrypt or verify with the other.  That is, if you have only the public key you can sign or encrypt a message for someone, but once you've done so not even you can read it.  Only the holder of the private key can decrypt the code.

This makes possible publishing the public key for anyone who wants it without breaking security.  The person now "signs" and "encrypts" their transmission using this, and the other end of the connection, which is the only holder of the private key, is the only person who can verify -- or intercept -- that transmission and return it to its original form. 

There is a further problem with this scheme, however, in that if I can intercept the transmission and get you to use a public key that is from an imposter I can pretend to be someone I'm not.  You then encrypt your password and send it, and I steal it, possibly completely transparently to you.

To avoid this risk the public key has to be signed ("vouched for") by someone trustworthy.  You can then use that trusted public key to verify the key you are about to use is authentic and really from the person who you think it's from.  Now if someone tries to be an imposter you will catch them and the attempt to steal your credentials (or data) fails.

There are two options here -- one is to buy a server certificate from a trust public authority.  That's what you do when you get an "SSL" certificate for your web site.  But for your personal use there is nobody you trust more than yourself -- right?  So what we'll do is exactly that -- we'll set up our own "Certificate Authority", or means of signing our own certificate.  Note that if someone steals your CA's private key you're just as screwed, so your security is important -- that private key should never be on a network-available anything, ever, because if it's stolen the thief can then start signing things as if they are you!

To do this we're going to use "OpenSSL", and we're going to edit a few things to work with StrongSwan .  If you're using OpenSSL for other things please be aware that this may break them, but if you're already using OpenSSL you probably understand the configuration changes and how to "put them back" when you're done.

OpenSSL keeps its configuration file in /etc/ssl/openssl.cnf.  We're going to edit that and change just a few things:

The line "dir" will be changed to "/usr/local/etc/ipsec.d" (default is ./demoCA)
The line  "certificate" will be changed to "$dir/cacerts/cacert.pem" (from $dir/cacert.pem)
The line "default_bits" we will change from 1024 to 2048 to strengthen the key.

There is a section called "[ req_distinguished_name ]" that you should update for your country, organization, state and such.  You don't NEED to do this but it makes life easier if you don't have to type these all the time and can just take the defaults.

Finally, there is a section called "[ usr_cert ]" that has options in it.  You want to add the following toward the end:

#
# Note - this is for IPSEC/Strongswan (extendedKeyUsage and SubjectAltName)
#
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
subjectAltName=DNS:myservers.domain.name
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
extendedKeyUsage=serverAuth

Adjust "myservers.domain.name" to be your server's public DNS address.  Note that you really probably want to change these per-certificate for machines if you're issuing more than one, but this again just changes defaults (and makes it easier to type without making mistakes later.)

The reason for these two entries is that clients want them.  Specifically, Windows 7 will barf if they're missing, and you will pull your hair out trying to figure out what's going on.  I did exactly that but after reading the various tutorials I figured out what had to go where.  Oh, and did I mention that none of the clients give you jack and crap in diagnostics telling you what they're unhappy about?  Yeah, they post up cryptic numeric error codes or worse, just "authentication failed" when you get it wrong.

Now we're ready to go.

Follow the tutorial here to set up your CA and gateway certificates: http://pages.cs.wisc.edu/~zmiller/ca-howto/

When you're done you should have a "cacert.pem" file in the cacerts directory under /usr/local/etc/ipsec.d directory, and a certficate for your sever's hostname in the "certs" directory.  There will also be a private key file under the "private" directory.

Now you need to remove the password you entered on the machine certificate from the private key.  This is necessary because the software must be able to verify the certificate.  Remember that in order to do that you need the other half of the key and since your computer is going to do this automatically it can't ask you for the password when it needs it.  To do this you take these steps:

# cp myserver.pem myserver-enc.pem
# openssl rsa -in myserver-enc.pem -out myserver.pem

You will prompted for the password and then the system will write out the unsecured copy of the private key into the file.  That file must not be compromised on your system.

Tired yet?  We're just about done -- now we're going to set up StrongSwan using the certificates you have generated.

In /usr/local/etc you have a file called "strongswan.conf."  Edit it and add a line under "charon" that reads "dns1 = xxx.xxx.xxx.xxx"  This should be your local DNS nameserver.  Normally this will be your gateway machine's IP address.  It doesn't have to be but it must be reachable over the tunnel, which means that generally it should be on your gateway machine.  This is the domain server that the clients that connect will be told to use, as their original DNS servers will "disappear" when they connect on the VPN.

Next we're going to edit "ipsec.conf"; this is where the meat is.

We want the file to look like this:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
# strictcrlpolicy=yes
# uniqueids = no

# Add connections here.

# Sample VPN connections

conn %default
keyingtries=1
keyexchange=ikev2

conn BB10
left=%any
leftsubnet=0.0.0.0/0
right=%any
rightsourceip=192.168.2.0/24
rightid=my@email.address
rightauth=psk
leftauth=pubkey
leftcert=my-host-certificate.pem
auto=add

conn Win7
left=%any
leftsubnet=0.0.0.0/0
leftauth=pubkey
leftcert=my-host-certificate.pem
leftid=@my-host-name
right=%any
rightsourceip=192.168.2.0/24
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%any
rekey=no
dpdaction=clear
dpddelay=300s
auto=add

We need two sections here, one for clients (such as the BlackBerry 10) that can use pre-shared keys and have no special requirements and then another for Windows 7 which does.  Windows 7 in particular gets pissed off about rekeying coming from the server (it wants to do it) so we turn that off.  We also use Windows' "unique" way of processing passwords (MSCHAPv2.)  We also tell it never to send the certificate from the right side of the connection, which it wants too.  

For Windows 7 you will need to follow the instructions here to import the certificate bundle into Windows 7's store.  See the "Storing a Windows 7 CA Certificate" link under that page for instructions.  This is a bit tricky but it does work -- just pay attention to the warnings or you'll import the CA certificate into the wrong place and then wonder why it doesn't work.

Note that IP range up there "rightsourceip" -- this is a declaration of an address pool from which the client's IP address will be drawn.  Make sure it does not collide with anything on your local network and is in "private" IP space (192.168.x.x is usable, as is 10.x.x.x.)  In particular be very careful not to overlap anything that DHCP may assign on your existing network or some really bizarre things can (and will!) happen.  When you connect to the VPN your client machine will get an address from this pool for the link.  See StrongSwan's documentation for other options (there are several) if you want to integrate address assignment and reporting for some reason.

"leftcert" is the certificate file for your gateway machine, relative to the "cert" directory.

You must also define how the system will find these files and the password(s) you wish to use.  Edit ipsec.secrets so it looks like this:

#
# Our certificate for the gateway; this is required for Windows 7

: RSA my-host-certificate.pem

#
# Passwords
#
%any : PSK "my-blackberry10-password"
%any : EAP "my-windows7-password"

The "%any" key means that any identifier is valid (any email address or login ID, for example.)  If you want to set up multiple users you can of course make specific entries for each person with different passwords; replace "%any" with the identifier in question.  The "RSA" line tells the system how to decode the host certificate (it's an RSA-encoded certificate file.)

Now type from the command line:

# ipsec start

You will likely get a couple of warnings; those are fine.

Type this:

# ipsec status

Security Associations (0 up, 0 connecting):
none

If you get that back from the status request it's running.

To check the machine certificate (very important!) you type this:

root@NewFS:/usr/local/etc # ipsec listcacerts

List of X.509 CA Certificates:

subject: "C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=customer-service@cudasystems.net"
issuer: "C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=customer-service@cudasystems.net"
serial: ea:e1:a3:cb:ff:b0:44:cf
validity: not before Apr 26 13:53:50 2013, ok
not after Apr 24 13:53:50 2023, ok
pubkey: RSA 2048 bits
keyid: 5d:a1:31:ae:45:18:dc:20:5d:96:0d:1d:51:05:5c:d6:7b:5f:18:2b
subjkey: 5d:d4:de:1a:41:66:ae:34:1c:1e:55:33:b0:78:e3:f8:26:5e:22:34
authkey: 5d:d4:de:1a:41:66:ae:34:1c:1e:55:33:b0:78:e3:f8:26:5e:22:34

This shows my Certificate Authority certificate, and that the system loaded it properly.  Note that there is no machine name anywhere in there -- this is not the gateway's cert.  Note that the "issuer" and "subject" are identical -- the CA signed its own certificate.

Now we check the gateway certificate to make sure that the software properly loaded it:

[root@NewFS /usr/local/etc]# ipsec listcerts

List of X.509 End Entity Certificates:

altNames: genesis.denninger.net
subject: "C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net, E=karl@denninger.net"
issuer: "C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=customer-service@cudasystems.net"
serial: 00
validity: not before Apr 26 13:58:18 2013, ok
not after Apr 24 13:58:18 2023, ok
pubkey: RSA 2048 bits, has private key
keyid: a2:d6:7e:56:84:02:2b:35:20:84:33:0c:5e:64:33:a3:68:c7:84:da
subjkey: a6:eb:7d:3b:91:a9:69:59:a0:7a:aa:6b:9e:cc:18:f8:57:6e:72:e9
authkey: 5d:d4:de:1a:41:66:ae:34:1c:1e:55:33:b0:78:e3:f8:26:5e:22:34

The "issuer" is the above certificate (the "cacert" subject line up above) -- those two must match.  They should, if you properly generated the certificate.

See that bolded line?  That has to be there.  If it's not then go back and make sure that the filenames in the "private" and "cert" directories are the same and that you performed the step above to strip the password off the private key.  Fix whatever is wrong and then do "ipsec stop" and "ipsec start" again.

Your VPN will not authenticate against a machine certificate if that "has private key" section is missing; it is necessary for the connection to work.

Now you need to import the CA certificate to your BlackBerry.  You cannot (for security reasons) do this over email (although it certainly is implied you can!) or over USB or ordinary file structure mounts as the directory won't show up!  Instead, go to Storage and Access, turn on "Access Using Wifi" and set up a password and, if necessary, your workgroup.  Once you do this your PC should be able to "see" the BlackBerry as a network device.  Open it and there will be a directory there called "certs".  Copy the file "cacert.pem" into that directory.

Then go to "Security and Privacy" and select Certificates.  Click "Import", make sure you're set to "Personal Trusted CA" and choose all three checkboxes (VPN, Web and Wi-Fi.)  You're only going to use VPN for now, but the other two may come in handy later (e.g. if you use this CA to sign a SSL certificate for your private web server.)

Choose "next" and the certificate you copied in should appear as importable.  Import it.  Now the phone knows your CA is valid and trusted.

You can now to go the BlackBerry's setup and set up a "Generic IKEv2" connection.  The screens look like this:

Note a couple of things here -- the server address is your domain name for the external interface of the gateway.  This must match the certificate you generated for the gateway; if it doesn't the connection will be rejected.  Your authentication type is "PSK" (pre-shared key) and the identifier is your email address (which you can put into the ipsec.secrets file if you have multiple users.)  The "gateway auth type" is "PKI", or Public-Key Infrastructure, and the ID type is Distinguished Name (that is, your DNS name of the gateway.)  You also select from the drop-down box the CA certificate you imported for your trusted CA (you can leave this at the default which will search all of them, but this is faster.)  I also clicked "Perfect Forward Security" which makes the negotiation take a bit longer (it takes six packet exchanges to set up the link instead of three) but somewhat improves security.  There is no need to change anything under "Advanced" (and you shouldn't unless you know what you're doing.)

Save the configuration.

You should now see the name of your VPN gateway; select it and if everything is working you'll get this:

If it fails to connect there are a few possibilities.  If you get a timeout the probability is that the server end has some sort of problem and you need to look at the log files there.  If you get an Authentication Error the problem can be on either end -- look in the server logfile first and if you don't see a reject there check the certificates -- either the gateway cert is wrong or it is not validating.  On FreeBSD the IPSEC log will be in /var/log/daemon if your system is reasonably close to defaults on where it logs things.

Once it's working you can select "Auto Connect" (visible at the bottom of the frame) and tell the phone you want it to use this any time you're on a cell connection.  It will then do so whenever you are on cellular data.  You can also apply the same profile to any WiFi connection you want -- this is very useful if you are in a coffee shop or other place with unsecured WiFi for all the obvious reasons!

One thing to note is that if the VPN is enabled it does not apply to hotspot downstream connections.  As such you need to set up a separate VPN connection on your laptop or other device.

Any device that will work with a pre-shared key (password) for user authentication and a server gateway certificate and is fully IKEv2 compatible should match and work against the "BB10" definition up above.  If it doesn't the problem is probably due to some hinky requirement on the client end.  Note that Windows 7 has such hinky requirements, which is why there are two sections up above instead of one.

Do this and you can enjoy secure internet access while on the road, even when in "public places" that have insecure WiFi.  This setup will also let you "see" inside resources (such as a fileserver) on your home or office network from your computer if desired, as the machine is for all intents and purposes on the local network when the VPN is in use.

Well well, what do we have here.

America needs more judges like James Fensom. Yesterday, the Panama City (Florida) adjudicator threw out felony drug charges against alleged pot dealer Jeffery Gage after depositions revealed that the police officers who arrested Gage had broken the law in order to make their case.

In his ruling (which you can read in full below), Fensom called the actions of the Bay County Sheriffs Office "outrageous...shocking, [and] disturbing," and declared that they "simply cannot stand."

From the record the cops not only illegally attached a tracking device to the suspect's car without a warrant but then twice trespassed to change the batteries in it, and worse, lied about it under oath while giving depositions to the defense and intentionally withheld the information from the defense.

That's illegal.  The premise of a public and fair trial requires that you be able to face your accuser, and that inherently includes having full access when defending yourself to the evidence against you.  When law enforcement intentionally destroys data that would tend to incriminate their own behavior and then conceals that fact your rights have been violated.

Why did they withhold the evidence?  That's easy -- it clearly demonstrated their illegal conduct and would have led to the exclusion of the evidence and search, without which the case collapses.

It's nice to see a judge that is willing to hold the cops to the letter of The Constitution.

The lesson?  Do not cooperate with law enforcement -- they will and do lie whenever it suits them right up until a Judge tosses their case.  

There's no reason to cooperate with or assist those who will intentionally violate your right to due process of law.