yp_master's comments

Indeed, that has been my solution.

But I'm seeing more and more authentication information being incorporated ("baked in", pre-installed, whatever) into browsers, whether it is lists of "valid" TLD's, certificates for "approved" CA's, or chosen individual website certificates.

Personally, I think this information should be cleanly separated from the software that may use it rather than pre-installed and "hidden from the user".

I prefer SSL termination on the client-side (my computer, my data only).

I like to have the ability to view my SSL traffic in plain text.

Should the user be able to see what her computer is sending out? I think she should. And encrypted traffic should not be some special exception.

Installing someone else's "MITM" software to decrypt SSL seems unnecessary.

It is much simpler to generate and install your own "fake" certificates that you control.

stunnel is one option.

There are others. socat, Pound, etc.

It should be the user who has the final decision over which certificates to trust. Users are the real "Certificate Authorities". They should have full control over encryption and decryption should they want to exercise it.

Is it wise to irrevocably delegate the decision to trust/not trust to website owners and browser authors? Perhaps those promoting solutions like "TACK" should give this more thought.

                             Schneier.com Has Moved

   As of March 3rd, Schneier.com has moved to a new server. If you've used a
   hosts file to map www.schneier.com to a fixed IP address, you'll need to
   either update the IP to 204.11.247.93, or remove the line. Otherwise,
   either your software or your name server is hanging on to old DNS
   information much longer than it should.

Ok, how should I "authenticate" that the site at the new address is the "real" one?

I know, I'll use OpenSSL and HTTPS!

It sounds like you are describing an "implementation problem" (i.e., OpenSSL's code sucks).

But then you suggest this could be a reason to throw out the notion of "ciphersuite flexibility".

Aren't these two separate things?

Perhaps the flexibility is good.

Maybe the problem is one of complexity and quality control.

Too many ciphers, and incoporating ones of dubious quality.

I still haven't seen anyone mention the other SSL libraries, e.g., axssl, polarssl, matrixssl, etc.

As for CA "infrastructure", what if the user uses OpenSSL's ca function?

She creates her own CA certificate and key and installs it on her device.

Then she downloads a website's certificate, signs it and installs it on her device.

Regardless of whether a wesbite has a paid-for certificate from a commercial "CA authority", she needs to make the final decision whether or not to trust it.

The user is the ultimate arbiter of which website certificates she wants to sign and install. (Not browser authors.)

Websites just need a central repository to publish their certificates.

They already do this for their "domain names" by having them published in a publicly accessible zone file (ideally, the user can download the zone file, as well as query it piecemeal over a network).

We as users trust that these zone files are accurate: specifically, we assume the IP addresses for the website's nameservers are correct.

Have you ever tried axssl or polarssl?

I am just curious; I make no endorsement of either.

"The fact is that no programmer is good enough to write code whic is free from such vulnerabilities."

"...you are kidding yourself if you think you can handle this better than the OpenSSL team."

Well, I can think of at least one example that counters this supposition. As someone points out elsewhere in this thread, BIND is like OpenSSL. And others wrote better alternatives, one of which offered a cash reward for any security holes and has afaik never had a major security flaw.

What baffles me is that no matter how bad OpenSSL is shown to be, it will not shake some programmmers' faith in it.

I wonder if the commercial CA's will see a rise in the sale of certificates because of this.

Sloppy programmer blames language for his mistakes. News at 11.

Anyone able to view this site without Javascript?

  1 notmagi.me:
  55 bytes, 1+1+0+1 records, response, authoritative, noerror
  query: 1 notmagi.me
  answer: notmagi.me 1800 A 207.97.227.245
  additional: . 32768 weird class

Nice.

It's such a simple and useful idea.

But being tied to what's in OpenSSL is scary.

I have been doing what spiped/spipe does using curvecpserver/curvecpclient.

How about using Soekris or Alix for a router instead of Netgear?

"But the book doesn't mention either technique..."

As other commenters are pointing out, the book's aim is to teach imperative programming with C to students of SML. It is not aimed at teaching functional programming in C.

The technique you describe -- using what UNIX offers, e.g., pipe and fork -- is used a lot by djb.

This book seems like a gentle intro to C.

And there's nothing wrong with keeping things simple in the beginning.

With respect to books and tutorials on C, I have seen much worse.

Master the basics of C, then go read djb's code for lessons on how to structure programs and smartly utilise what UNIX has to offer. Keep K&R and Stevens nearby for reference.

A classic example is passing file descriptors instead of using a pipe function that opens a shell. There is no book on C that teaches that, but it is elegant programming indeed.

Even when one strives to keep things simple, C (and UNIX) have many gotchas.

There's a lot to learn.

This book doesn't overwhelm the reader.

Personally, I like the approach.

Lots of short consistent examples.

Lucid writing style, too.

Here are the answers:

  T
  F
  F

FWIW, IAAAL.

I suspect not many readers understand the above facts.

If you purchase a US patent, this is what you get: a right to sue.

Nothing more and nothing less.

If you have any doubts that the above is true, ask your lawyer.

Knowing exactly what a patent is should make you think more carefully about what a patent may or may not "incentivize".

True or false? A patent is a government-granted right to sue. A patent grants a license to produce the invention. A patent grants a "monopoly"; success is court when suing challengers is "guaranteed".