Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I no longer have an old-school cert on my HTTPS site

rachelbythebay.com

Post reply on HN
Print view View original

431–437 of 437 posts

Re: Why I no longer have an old-school cert on my HTTPS site

#431

Post by g-b-r »

g-b-r wrote: post #109
Avamander wrote: post #43

Earlier quoted context omitted.

> It's that more complex stuff is inherently more prone to security vulnerabilities That's overly simplifying it and ignores the part where the simple stuff is not secure to begin with. In the current context you could take a HTTP client with a formally verified TLS stack, would you really say it's inherently more vulnerable than a barebones HTTP client talking to a server over an unencrypted connection? I'd say ther…

The alternative of the article was ACME vs other ways of getting TLS certificates, not https vs http. Of course plain http would be, generally, much more dangerous than a however complex encrypted connection

Why the heck was this downvoted

Re: Why I no longer have an old-school cert on my HTTPS site

#432

Post by g-b-r »

bigstrat2003 wrote: post #135
g-b-r wrote: post #42

Earlier quoted context omitted.

For god's sake, however complex ACME might be it's better than not supporting TLS

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

Do you consider only religion, health and political data to be sensitive??

What someone chooses to read on a blog is no one else's business, and can be very sensitive.

Re: Why I no longer have an old-school cert on my HTTPS site

#433

Post by g-b-r »

nssnsjsjsjs wrote: post #314
mort96 wrote: post #294

Earlier quoted context omitted.

> (valid I think even if I’ve never encountered it to my knowledge) Visitors to your website may encounter it. Do you not care that your visitors may be seeing ads? You're also leaking what your visitors are reading to their ISPs and governments. Maybe you don't consider anything you write about to be remotely sensitive, but how critically do you examine that with every new piece you write? If you wrote something whi…

I agree but SSL doesn't encrypt the IP so there is that information leaked. That isn't to say don't use SSL but more it isn't 100% privacy protection from middlemen.

Not there being 100% protection doesn't make it pointless to have any protection

Re: Why I no longer have an old-school cert on my HTTPS site

#434

Post by GoblinSlayer »

tialaramex wrote: post #200
GoblinSlayer wrote: post #141

Earlier quoted context omitted.

>ASN.1 and X.509 are devilishly complex Most of it is unused though, only CN, SANs and public key are used.

You really shouldn't need CN (but it's convenient for humans) however there are a bunch of other interesting things in the X.509 certificate, lets look at the one for this site: Issuer: We need to know who issued this cert, then we can check whether we trust them and whether the signature on the certificate is indeed from them, and potentially repeat this process - this cert was issued by Let's Encrypt's E5 intermedi…

I think most of that is generated by CA. Does it even allow to specify arbitrary validity time?

Re: Why I no longer have an old-school cert on my HTTPS site

#436

Post by em-bee »

eximius wrote: post #210
eadmund wrote: post #201

Earlier quoted context omitted.

> I feel like not understanding why JSON won out is being intentionally obtuse. I didn’t feel like my comment was the right place to shill for an alternative, but rather to complain about JSON. But since you raise it. > JSON can easily be hand written, edited, and read for most data. So can canonical S-expressions! > Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix ev…

For you, perhaps. For me, the former is denser, but crossing into a "too dense" region. The JSON has indentation which is easy on my poor brain. Also, it's nice to differentiate between lists and objects. But, I mean, they're basically isomorphic with like 2 things exchanges ({} and [] instead of (); implicit vs explicit keys/types).

even as a fan of s-expressions (see my other comment), i have to agree. but the problem here is the formatting. for starters, i would write the s-expression example as:

    (urn:ietf:params:acme:error:malformed
     (detail      "Some of the identifiers requested were rejected")
     (subproblems ((urn:ietf:params:acme:error:malformed
                    (detail     "Invalid underscore in DNS name \"_example.org\"")
                    (identifier (dns _example.org)))
                   (urn:ietf:params:acme:error:rejectedIdentifier
                    (detail     "This CA will not issue for \"example.net\"")
                    (identifier (dns example.net))))))
the alignment of the values makes them easier to pick out and gives a visual structure

but, i would also argue that the two examples are not equivalent. what is explicitly specified as "type" and "value" in the json data, is implied in the s-expression data. either format is fine, but it would be better to compare like for like:

an s-expression equivalent for the json example would look like this:

    ((type   urn:ietf:params:acme:error:malformed)
     (detail "Some of the identifiers requested were rejected)
     (subproblems 
       ((type   urn:ietf:params:acme:error:malformed)
        (detail "Invalid underscore in DNS name \"_example.org\"")
        (identifier
          (type  dns)
          (value _example.org)))
       ((type   urn:ietf:params:acme:error:rejectedIdentifier)
        (detail "This CA will not issue for \"example.net\"")
        (identifier
          (type  dns)
          (value example.net)))))
or the reverse, a json equivalent for the s-expression example:

    {
      "urn:ietf:params:acme:error:malformed":
      {
        "detail":     "Some of the identifiers requested were rejected",
        "subproblems": 
        [
          "urn:ietf:params:acme:error:malformed":
          {
            "detail":     "Invalid underscore in DNS name \"_example.org\"",
            "identifier": 
            {
              "dns": "_example.org"
            }
          },
          "urn:ietf:params:acme:error:rejectedIdentifier"            
          {
            "detail":     "This CA will not issue for \"example.net\"",
            "identifier":
            {
              "dns": "example.net"
            }
          }
        ]
      }
    }
a lot of the readability depends on the formatting. we could format the json example more dense:

    {"urn:ietf:params:acme:error:malformed": {
      "detail":     "Some of the identifiers requested were rejected",
      "subproblems": [
        "urn:ietf:params:acme:error:malformed": {
          "detail":     "Invalid underscore in DNS name \"_example.org\"",
          "identifier": {
            "dns": "_example.org" }},
        "urn:ietf:params:acme:error:rejectedIdentifier": {
          "detail":     "This CA will not issue for \"example.net\"",
          "identifier": {
            "dns": "example.net" }}]}}
doing that shows that the main problem that makes json harder to read is the quotes around strings.

because if we spread out the s-expression example:

    (urn:ietf:params:acme:error:malformed
      (detail      "Some of the identifiers requested were rejected")
      (subproblems
        ((urn:ietf:params:acme:error:malformed
           (detail     "Invalid underscore in DNS name \"_example.org\"")
           (identifier 
             (dns _example.org)
           )
         )
         (urn:ietf:params:acme:error:rejectedIdentifier
           (detail     "This CA will not issue for \"example.net\"")
           (identifier
             (dns example.net)
           )
         )
        )
      )
    )
that doesn't add much to the readability. since, again, the primary win in readability comes from removing the quotes.

Re: Why I no longer have an old-school cert on my HTTPS site

#437

Post by alterom »

NooneAtAll3 wrote: post #391
alterom wrote: post #352

Earlier quoted context omitted.

>> Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? >That sentence has four negations and I honestly can't figure out what it means. This example is halfway as bad as the one Orwell gives in my favorite essay, "Politics the the English Language"¹. Compare and contrast: >I am not, indeed, sure whether it is n…

that Orwell quote can be saved a lot by proper punctuation I am not, indeed, sure*,* whether it is not true to say that the Milton *(*who once seemed not unlike a seventeenth-century Shelley*)* had not become *-* out of an experience *-* ever more bitter in each year, more alien (sic) to the founder of that Jesuit sect*,* which nothing could induce him to tolerate.

Has the proper punctuation allowed you to see that there's an extra negation there that makes the sentence say the exact opposite of what the author intended it to say?
Post reply on HN