Who's waging war against HTTPS?

In April 2016, Let's Encrypt went live.  Let's Encrypt is a group making it significantly easier to encrypt web traffic.  Some entity seems to have begun waging a war of public opinion against them.

Previous to their existence conveniently securing web traffic meant paying money to a company which would then provide you with a "certificate" for your website.  Servers and browsers use these certificates to create a secure communication path between them.  This secure path (denoted by URLs starting with "https://" rather than "http://") prevents entities between your computer and the website from seeing or altering the data being sent to and from the website.

Because of the cost and inconvenience many websites used unsecured connections.  However, places like banks, shopping, and healthcare providers have pretty much always used secure connections.  It took a few years but eventually social media websites began using secure connections by default as well.

Before Let's Encrypt, millions of websites only had their content available via unsecured communications.  For many people, like myself, running websites without any goal of making money from them the expense and hassle of certificates wasn't worth it.  Now, my websites are all available through secured connections, for free, thanks to Let's Encrypt.  (To be clear, many websites still haven't taken advantage of this service yet, but they at least have the option now.)

But, if banks and such use secure connections anyway, why do we care about Let's Encrypt, should I care if "someone" can see that I'm reading this blog post?


On March 28 Congress voted to repeal FCC regulations that prevented your Internet Service Provider (ISP) from spying on your web traffic and using that information to their financial benefit.  The regulations also prevented ISPs from altering your web traffic for similar purposes (e.g., injecting ads into a webpage when you view it).

Maybe you don't care if Comcast, or AT&T, or Verizon knows you like to knit and shop at JoAnn's Fabrics.  But maybe you'd be concerned if they started selling information to other companies about you visiting cancer treatment websites, or rape support groups, or divorce attorneys, or any number of kinds of sensitive information.

Using encrypted connections doesn't solve this problem entirely, but it makes the information available to your ISP a lot less useful.  For example, your ISP would still be able to tell you're looking at Amazon.com, but they wouldn't be able to tell if you're looking at knitting needles or books about infertility treatments.

Regardless of your stance, someone seems to be working hard to turn public opinion against Let's Encrypt and again make it harder to encrypt web traffic.  Articles like this one: "14,766 Let's Encrypt SSL Certificates Issued to PayPal Phishing Sites" have been showing up all over the Internet recently, all making similar claims that it is Let's Encrypt's fault that people are falling for fake PayPal scam websites.

I don't think it's actually PayPal behind these articles, because this problem is nothing new, but the concerted, direct attack on Let's Encrypt is new.

Let's Encrypt does not verify the identity of the person requesting a certificate (which other certificate providers will do for steep fees, $300+ per year, these "verified" certificates are significantly different than the "non-verified" certificates issued by Let's Encrypt).  Instead Let's Encrypt verifies that you control the website for which you're requesting a certificate, slightly different.

The argument made by these articles is that now someone can get _a_ certificate for "paypall.com" and people will think that the green lock icon on their browser means they're connected to "paypal.com" instead.  Which it doesn't and never has.  The "verified" certificates show up differently in your browser.  For example, on this blog you'll see something like this:

With a "verified" certificate you'll instead see something like this:

This indicates that the company issuing the certificate verified that the company requesting the certificate is "PayPal, Inc." and the certificate is for "paypal.com".

The articles want you believe Let's Encrypt is somehow at fault if people end up at "paypall.com" with a green lock and think it's "paypal.com".  Let's Encrypt isn't providing "verified" certificates or trying to solve that problem.  The problem they're trying to solve is that too much web traffic is unencrypted by default because certificates were expensive and inconvenient.

Someone with a vested interest in being able to read and/or modify your web traffic has been working really hard to get these articles out and make it look like some kind of "public safety" issue.

I have no idea who that entity may be, but it's making me really annoyed.  Let's Encrypt is a good thing for anyone that thinks that their Internet communications should be private by default.

Update 3/31: Engadget just ran one of the attack pieces too: "When the 'S' in HTTPS also stands for shady".  Which is the most mainstream source running these articles that I've seen thus far.

To be completely clear, when a URL starts with HTTPS it only means that your connection is encrypted between your computer and the website--it has never meant anything about who is running the website is or whether the website operator is trustworthy.

Django Form Label for Many-to-Many with Extra Fields

I'm working on a Django application at work that has several Many-to-Many relationships that have extra fields attached to them. Setting this up using the "through" parameter on the field definition is described in the Django documentation.

My trouble came in when it came time to render this information out to the user in a form so they could update the extra fields.  From the user's perspective the relationship can't be changed, but the extra fields could be.

Extending Django's example usage about band membership, if the user were viewing the information for "The Beatles" and including a formset for all band members the form would normally render something like this:

Group Name: The Beatles
    Group: The Beatles
    Person: Ringo Starr
    Date Joined: 14 August 1962
    Group: The Beatles
    Person: John Lennon
    Date Joined: 01 August 1960

But this is a little obtuse if the purpose of the form is to allow the user to edit the "Date Joined" value for each band member.  We can whittle the form down by telling the formset to only render the "Date Joined" field [by passing fields=('date_joined',) to modelformset_factory], but then we get this:

Group Name: The Beatles
    Date Joined: 14 August 1962
    Date Joined: 01 August 1960

Now we can't tell to which person each date applies.

Adjusting the form so that the label "Date Joined" was instead the appropriate band members name seems like such a simple thing to change.  But I didn't want to hand-write the form as it was already being automatically built and rendered for me using using modelformset_factory and Crispy-Forms.

It took me most of a day to figure it out and in the end it was pretty simple.  I only need to implement a custom Form that overrides the constructor and sets the label using the object instance before it gets thrown away:

class MembershipForm(forms.ModelForm):
    def __init__(self, *args, **kwargs):
        super(MembershipForm, self).__init__(*args, **kwargs)
        if kwargs['instance'] and kwargs['instance'].person:
            self.fields['date_joined'].label = kwargs['instance'].person.name
            self.fields['date_joined'].label = 'No Person'
    class Meta:
        model = Membership
        fields = ['date_joined']

And now our output looks something like:

Group Name: The Beatles
    Ringo Starr: 14 August 1962
    John Lennon: 01 August 1960

Since it took me most of a day to figure this out, and I couldn't find anything specifically addressing this on the Internet, I wrote this up so hopefully the next person (or me in the future once I've forgotten this) will have an easier time figuring it out.

2016 Family Adventure - Part 5: Kidcity & CT Science Center

On Monday, the 17th, we took the girls to Kidcity Children's Museum in Middletown.  Mom was watching Ryan again and brought him with us.  It's a pretty impressive set up; intricately designed rooms with almost all of the equipment in proper working order.  The girls couldn't get enough.  We practically had to drag them out after 3.5 hours.


While wandering about in the science-fiction-y space room Corinne wandered off and got herself stuck in an elevator and freaked out.  Grandma rescued her, but now both our kids probably have elevator complexes.

Heather serving up bowls of water vapor at the bar:2016-10-17_13-29-06


Running the cash register:2016-10-17_13-38-37


"I'm a sea creature!"2016-10-17_13-45-39


The Fishery was pretty cool.  The fish have a screw in their mouths, the conveyor belt has magnets to which you can stick the fish.  We spent a lot of time in the Fishery.  Conveyor belts, sorting baskets, slides, elevators--so much fun!2016-10-17_14-06-42 2016-10-17_14-10-25 2016-10-17_14-24-05


Climbing the monkey bars in the sound room:2016-10-17_14-41-11


Riding the see-saw:2016-10-17_14-42-40


The Medieval Room was also really cool: crossbows, a carrot farm, a corn field, a bread oven, a "water" wheel, building blocks!2016-10-17_14-52-32


Heather put on a puppet show for me:2016-10-17_15-30-21


Snack time:2016-10-17_15-59-36


And one tuckered out Heather at the end:2016-10-17_16-56-24


Then on Tuesday we headed up to Hartford to see the Connecticut Science Center.  The school groups and older kids weren't allowed in the water zone, which made it the perfect place for Heather and Corinne.



And Corinne got herself soaking wet by pouring water all over herself.  So Jess bought a "Sweet as Pi" onesy for her to wear the rest of the day.2016-10-18_11-33-16


Apparently you can get a stream of water to shoot up higher if it hits a surface and then spreads out horizontally instead of falling back down on itself.  Who knew?2016-10-18_11-41-02


Heather giving her green-screen weather report:2016-10-18_12-57-45


Driving the ambulance:2016-10-18_13-29-20


Heather got a personal demonstration about inertia and centrifugal forces:2016-10-18_14-04-41


After the school groups leave they open up the dinosaur-bone digging pits:2016-10-18_14-12-52 2016-10-18_14-31-52


Astronaut Heather ready to explore the solar system.2016-10-18_14-49-51


They had an entire exhibit about Leonardo da Vinci's various inventions:2016-10-18_15-25-18 2016-10-18_15-27-40


The sound exhibit was fun too.  Corinne thought the laser harp was a great place to sit (notice the laser beams on her head).2016-10-18_15-50-07

After a long day of fun at the science museum it was back home to play with cousins in the back yard.

2016-10-18_17-15-16 2016-10-18_17-20-38 2016-10-18_17-24-06 2016-10-18_17-24-30

Up next Newport Mansions.


Let's Encrypt Certbot Cron Job

I switched my webservers over to using Let's Encrypt to obtain SSL certificates.  Everything looked great, but the update job would fail to run from Cron.

At first I had no errors to go on because my systems aren't configured with a mail program so Cron couldn't email me the errors.  Rather than configure a mailer, I just piped the output to another log file by creating a folder under /var/log with permissions for my user and then updating cron so that

[command here] >> /var/log/certbot/certbot_cron.log 2>&1

was at the end of the command.  So my full crontab entry is now:

36 2 * * * /home/kyle/certbot-auto renew --quiet --no-self-upgrade >> /var/log/certbot/certbot_cron.log 2>&1

Then I discovered the job was failing because:

sudo: no tty present and no askpass program specified

I have certbot-auto setup from my regular user account, which works great, except for the cron job.  If I put the cronjob in the root's crontab, it doesn't know about the existing configuration in my user account so it tries to start over.

After some digging around and failing to find an exact solution to this problem I managed to get it running and made this post to help the next poor unfortunate soul.

I edited the sudo rules using:

sudo visudo

And added to the end of the file:

kyle ALL=NOPASSWD:SETENV: /home/kyle/.local/share/letsencrypt/bin/letsencrypt, /usr/sbin/service apache2 *

This allows my account to execute the letsencrypt program and control the apache2 service without providing a password.  SETENV allows it to set environment variables.  I added it to get around the error message:

sudo: sorry, you are not allowed to set the following environment variables: CERTBOT_AUTO

I don't know if this is the best way of getting the cronjob to run, but it seems to be working.  It honestly still isn't clear to me if one should just do all the letsencrypt stuff as root or not.  That would probably avoid this issue, but if that's the case they should just say it somewhere.  Instead it works as non-root, but the cronjob to automatically update it doesn't.  And the automatic updating is kind of the point.

I don't know if it makes a difference, but these servers are running Ubuntu 14.04.

Scientific Models

Something I think gets lost in scientific education is what a "model" truly is.  We blur the line between model and reality until we forget that a model is exactly that--a model.

This conflation of terms is understandable when we talk about things we experience in our day-to-day lives.  We say things like, "when I toss a ball it moves in an arc," and not, "we can model the motion of the ball using an arc."  We don't worry about whether the ball actually moves in an arc or not--that distinction isn't particularly meaningful.

But when we start learning about more complex phenomena the distinction between the model and reality can become very important. A model is simply a representation of some process or phenomenon that we observe.  An acceptable model will match the observed behavior in a consistent, coherent manner.  And a good model will allow us to make accurate predictions about future events.

The "accepted" model for an observed behavior tends towards the model that allows us to make the most accurate predictions.  Utility is the lifeblood of models.

But a model, even one that allows us to make very accurate predictions, may not tell us anything about what's really happening.

I stumbled upon an interesting example of this dichotomy between models and reality while reading Blind Watchers of the Sky.  Through the 16th century it was "known" that celestial bodies moved in circles.  This was an accepted fact because celestial bodies were created by God and uncorrupted by man, God is perfect, and circles are the perfect shape.  The celestial bodies clearly moved, so they must move in circles.  This was the dogmatically accepted model of the time.

With crude measurements the concept of the planets moving in perfect circles seemed to fit well enough.  But, eventually measurements got better and it became clear that they couldn't be moving in just simple circles.  Since the perfect aspect couldn't be challenged, the discrepancies were accounted for using epicycles (smaller circles moving along the larger circle) and other such complexity.

The model became more accurate, but was that truly how the heavens functioned?

Eventually Kepler proposed a radically different model.  But rather than what his new model was, the pertinent part is how he presented it.  He essentially said something like, "Hey everyone, look, we all know circles are perfect, and the heavens are perfect because God created them and God is perfect; I'm not saying anything otherwise.  However, I found out that if we model the motion of the planets using ellipses the calculation is easier and the results are more accurate!"

The argument wasn't whether the planets truly moved in circles or ellipses, that was a foregone conclusion at the time.   Instead it was the presentation of a model that allowed for more accurate predictions.  How the planets really moved didn't particularly matter.


An example I like to use to help separate the concepts of models from reality is this:

There is a thing on my desk.  I believe I can accurately predict how it will behave if I apply the model "spoon" to it.  I pick this object up and use it to eat soup.  My "spoon" model was accurate.  Jess now comes in the room and asks to use the item and proceeds to use this object in a way that no "spoon" I know of can be used.  She uses this thing to stab food and put it in her mouth.  The way she uses it would be better modeled by what I call a "fork."  So is it a spoon or is it a fork?

I could claim that sometimes it's a fork and sometimes it's a spoon.  That seems rather bizarre, yet it matches my observations.  Sometimes it acts like the things we call "spoons" and sometimes it acts like the things we call "forks."  But that doesn't mean it is both or that it transforms from one to the other.  It is what it is.  It only means that these models can both be useful in describing this thing depending on the circumstances.  However, a more accurate model is to realize it's something else entirely.  We need a new model we'll call "spork."


As one attempts to comprehend modern physics one is forced to separate "model" from "reality" if for no other reason than sanity.  When sub-sub-atomic particles were detected and their properties mapped scientists really just needed words to assign to these things they were observing that could only be indirectly observed.  So we ended up with terms like "spin" where nothing is really spinning, and "color" when nothing emits a visible-light wavelength, and other properties.  Then a fundamental set of 6 particles with various values for those properties was identified and needed names and we ended up with "Up", "Down", "Charm", "Strange", "Top", and "Bottom" quarks.

I don't know what reality really is, but we keep building models with greater and greater accuracy that enable us to better predict future events.  At some level the distinction becomes irrelevant, but that's only true right up until reality does something our model says is impossible.  And then, it's time for a new model.