OpenBSD Journal

Undeadly and HTTPS

Contributed by tj on from the crowdsourcing dept.

We here at Undeadly are looking to move the site to HTTPS-only. It's been discussed for quite a while, but there's one roadblock that we're looking for some help to overcome.

The authentication system (how you log in to post comments) is currently an stunnel instance listening on port 443, while the main site is OpenBSD's httpd running on port 80. httpd serves static content and the Undeadly CGI binary. stunnel's only job is checking credentials and (if successful) handing out a cookie. Getting rid of this old "split" setup requires code changes so that everything can be behind TLS, not just the authenticating bit.

In general, a lot of the code needs some major cleanup as well, so this may be a big project. We'd like to see a lot of the security constructs completely redone in a better way.

If you're a C coder, the source for the site can be found here. Send us an email if you're interested in helping.

(Comments are closed)


Comments
  1. Comments
    1. By phessler (phessler) on http://www.openbsdfoundation.org/donations.html

      > I do have a semi-in-progress rewrite in Mojolicous::Lite that unfortunately $work has gotten in the way of, most of the backend work to get it reading existing articles is complete, it's mostly details left now.

      Personally speaking, but as an Undeadly editor, this would be far and away my preferred solution. If people want to hack, I encourage hacking on _this_ :).

  2. By foo (151.67.46.127) on

    why don't u use PHP sessions via CGI on HTTPS ?

    Comments
    1. By foo (151.67.91.62) on

      Don't forget to patch PHP with Suhosin:
      https://suhosin.org/stories/feature-list.html

  3. Comments
    1. By Ralph Siegler (63.156.247.204) on

      > Please don't.
      >
      > Just don't do it.
      >
      > There is no valid reason to deny access to the public content for people who, one way or another, cannot or don't want to use HTTPS.
      >
      > Please don't establish a policy to deny readers of access.
      >
      > Thanks.



      Your password to this site is not public content. Maybe the site owners care about that. Maybe you should too.

      http is going away, the internet will be all https very soon. There is no reason you can't use an https graphical or command line browser, there are plenty available at no cost for all general purpose operating systems in common use.

  4. By Anonymous Coward (80.53.251.245) on

    As a side note I find it a bit odd that OpenBSD related project uses pesky sudo instead of doas ;)

  5. By Anonymous Coward (46.165.230.5) on

    I do not understand the motivation behind undeadly.org switching to HTTPS only.

    It is a journal of information accessible to the public. What kind of information is sensitive or private, to the extent that it would need HTTPS?

    Mandating encryption on a public-access journal site with public-access comments will probably use more resources, thanks to encryption and decryption.

  6. By ian (24.138.98.109) on

    Some of you guys need to get out more. The entire web is moving to https, and Google is even down-ranking (now or soon) sites that aren't encrypted. What do you have against encryption? It offers some protection against malicious tampering; if you don't encrypt it, you have none. If you don't encrypt, blackhats can change an article on "Why I use OpenBSD" to "Why I hate OpenBSD", or even "Why I hate Windows", and you'll be left wondering WTF is that doing on Undeadly.

    Comments
    1. By Anonymous Coward (108.34.172.190) on

      > Some of you guys need to get out more. The entire web is moving to https, and Google is even down-ranking (now or soon) sites that aren't encrypted. What do you have against encryption? It offers some protection against malicious tampering; if you don't encrypt it, you have none. If you don't encrypt, blackhats can change an article on "Why I use OpenBSD" to "Why I hate OpenBSD", or even "Why I hate Windows", and you'll be left wondering WTF is that doing on Undeadly.

      Some of you guys need to ramp down the paranoia. While HTTPS is needed for secure loging and commerce, it's not needed for informational sites. I have full control over filtering HTTP content, not so much so with HTTPS.

      The rest of your message is pure FUD, and would only occur on a site that isn't being properly monitored and maintained. The dangers most web viewers face is from malicious adds.

      Over the years this site has been a great resource, but that will end when I can connect via plain HTTP.

      Comments
      1. By Anthony J. Bentley (bentley) anthony@anjbe.name on https://www.anjbe.name/

        > Some of you guys need to ramp down the paranoia. While HTTPS is needed for secure loging and commerce,

        So you hit the login button on Undeadly, which leads to a prompt for you to transmit your password over HTTPS. Except if you're browsing Undeadly over HTTP, an attacker can trivially modify the login link to point to an unencrypted page. Now you're MITM'd for the entirety of your login session. Will you notice? Most people won't.

        > it's not needed for informational sites.

        Personally I prefer browsing over HTTPS even on sites I don't log into like Wikipedia, OpenStreetMap, and the Internet Archive. Why make it trivial for people to know what subject I'm reading about at any given moment? Sure, it's still possible to derive information from HTTPS traffic... but without encryption you're handing that information to them on a silver platter.

        > The dangers most web viewers face is from malicious adds.

        It's also common practice in some places for ISPs or wireless access points to insert advertisements into webpages. Of course, they can't do that in a HTTPS page without triggering a big fat warning in the browser informing you that your data stream's been compromised.

    2. By bearserker (81.64.117.236) bearserker@mailoo.org on

      Who cares about what google up-ranks or down-ranks ?
      And why should we go "where everybody else goes" like sheeps ?
      I'm fundamentally *NOT* against encryption, but I don't see a good reason for the "only" in "HTTPS-only".

    3. By Anonymous Coward (174.21.146.150) on

      > What do you have against encryption?

      Self-signed certs are too challenging for users; even those with know-how may feel benefit from being able to use many browsers (e.g., one built into a friend's phone) without needing to deal with certs.

      As for non-self-signed certs, when I checked some years back, the only decent freebee I found was from StartSSL. Rather than just jot down a passphrase in a file that I keep secure, I needed to keep track of another file that is used to identify me. That procedure is much more inconvenient just because it is less common. Life marched on, and I didn't remember to renew in just under one single year, so naturally that led to my sites' HTTPS breaking. I believe that's happened twice so far. Such ongoing maintenance isn't needed for HTTP.

      When I checked LetsEncrypt last November, they hadn't yet started the public beta. Sometimes I'm okay with exploring a process, particularly if I feel it is worthwhile because I can document the process to make things easier later. Other times I'm less interested in exploring just because I'm more rushed. I figured that if the service is beta, details about my documentation may have an especially high likelihood of becoming nullified by changes to a beta service. So I decided to try to wait until after the Beta period.

      None of these struggles exist with regular HTTP. HTTP is simply just easier to set up (fewer steps). HTTP is easier to inspect (great for some purposes, including educational). HTTP does use fewer resources. The split between HTTP and HTTPS (using different default ports) is one way to help categorize very sensitive traffic from traffic that the whole world is very welcome to see.

      > The entire web is moving to https,

      Umm... no. Google, Facebook, and many others? Yes.

      > Google is even down-ranking (now or soon) sites that aren't encrypted.

      This reminds me of Google informing me, via Webmaster Tools, that my websites don't properly specify a size of a viewing portal, which affects mobile browsers.

      A lot of my archived content was initially created for IE 3 and Netscape 4 and such simple HTML has been working just fine, even to this date. Much of my publicly archived content has a file modification date from last millennium. The few files that have newer dates are exceptions, and it is nice to be able to easily spot them. Google clearly has some mastery of HTML and is in charge of the Android platform. But rather than making sure their browser can make a good decision about a default amount to zoom in on content, they want me to go through all my content to add a tag, which has the effect of increasing download times for everyone?

      I understand Google has a desire to support mobile experiences, and they have a desire to thwart NSA spying, but I don't want to expend a lot of my own effort just to support whatever whim Google decides to promote. Helping users to find relevant content is the foundational service that made Google popular. If they wish to risk some of their achieved success with that foundation, in order to further promote other agendas like an HTTP-icide initiative, they have the right to perform whatever balancing act they wish. The further they push in a direction that dismisses relevant content, the further they risk more emigrants.

      Comments
      1. By sthen (82.68.199.130) on

        > When I checked LetsEncrypt last November, they hadn't yet started the public beta. Sometimes I'm okay with exploring a process, particularly if I feel it is worthwhile because I can document the process to make things easier later. Other times I'm less interested in exploring just because I'm more rushed. I figured that if the service is beta, details about my documentation may have an especially high likelihood of becoming nullified by changes to a beta service. So I decided to try to wait until after the Beta period.

        Public beta started 3 December, they are now in production.

        > This reminds me of Google informing me, via Webmaster Tools, that my websites don't properly specify a size of a viewing portal, which affects mobile browsers.
        >
        > A lot of my archived content was initially created for IE 3 and Netscape 4 and such simple HTML has been working just fine, even to this date. Much of my publicly archived content has a file modification date from last millennium. The few files that have newer dates are exceptions, and it is nice to be able to easily spot them. Google clearly has some mastery of HTML and is in charge of the Android platform. But rather than making sure their browser can make a good decision about a default amount to zoom in on content, they want me to go through all my content to add a tag, which has the effect of increasing download times for everyone?

        Actually mobile chrome doesn't do all that bad a job of that. IME adding the viewport tag (all ~70 chars of it) is a bigger help for mobile firefox than chrome.

    4. By sthen (82.68.199.130) on

      > If you don't encrypt, blackhats can change an article on "Why I use OpenBSD" to "Why I hate OpenBSD", or even "Why I hate Windows", and you'll be left wondering WTF is that doing on Undeadly.

      https doesn't prevent that.

  7. By Chas (147.154.235.102) on

    Why don't you just move the current stunnel to 1443, then grep for "https" in the codebase and change it to "https://...:1443" and switch the CGI stunnel to the new port?

    Then install a new stunnel that just points does a connect to localhost:80, and the TLS content will be exactly what port 80 spits out.

    Comments
    1. By Anonymous Coward (92.40.18.89) on

      Euuuuuwwwww .....

      Comments
      1. By Chas (147.154.235.102) on

        > Euuuuuwwwww .....

        This is life. You can have quality, speed, or price, but you only get to pick two.

        In any case, moving the CGI to 1443 is a no-brainer. But if you really enjoy refactoring, then by all means wear out a keyboard.

        Comments
        1. By Anonymous Coward (188.29.31.236) on

          > > Euuuuuwwwww .....
          >
          > This is life. You can have quality, speed, or price, but you only get to pick two.
          >
          > In any case, moving the CGI to 1443 is a no-brainer. But if you really enjoy refactoring, then by all means wear out a keyboard.

          TLS on port 80 ? CGI on 1443 ? hardcoding port 1443 in the source ?

          I could be wrong, maybe there is something in the config I've missed, but otherwise putting the whole site on port 443 and redirecting port 80 to https is obvious to the browser, will cause less problems for users and should be less work for the admins.

  8. By Anonymous Coward (91.196.8.156) on

    static const char *secret = "lw1N0mN0t8a24UR4NY12AT55p/23FxJ9H6+NReXed8nTZJraO0g";

    No longer a secret.

    Comments
    1. By Anonymous Coward (46.14.192.77) on

      > No longer a secret.

      Bit of a misnomer, it's merely a (global) salt for the password hash file, not the shared secret between the components. That would have been a blunder (it is read from file and not hardcoded in the source). Thanks for looking ;)

      Comments
      1. By Anonymous Coward (208.95.100.30) on

        > > No longer a secret.
        >
        > Bit of a misnomer, it's merely a (global) salt for the password hash file, not the shared secret between the components. That would have been a blunder (it is read from file and not hardcoded in the source). Thanks for looking ;)

        If you allow your salt to get published, that eliminates the benefits of having a salt, right? Doing a brute force attack is then possible for "shorter" passwords as the attack adds in your salt for every try at matching the hash. Explain again, how exposing your salt is NOT a big deal?

        Comments
        1. By Anonymous Coward (213.3.30.106) on

          The purpose of the salt is to make pre-computed hash tables (of dictionionary entries) useless (a fast and cheap attack).

          If you figure out the salt, and you have obtained the password hash file, you can start trying dictionary entries, but you still can't use a pre-made table, you must build one for just this salt.

          Optimally, you'd use a random per-user salt and store it together with the password hash, so the attacker has to repeat the processes for every single user (and not all users at once).

          When the password file leaks, the attacker does know the salts, but it still foils the cheap attack.

          So, the point is not that the attacker doesn't know the salt(s).

          Or, put differently, now that you know the salt, but don't have the password hash file, what can you do?

        2. By Anonymous Coward (66.215.42.218) on

          > If you allow your salt to get published, that eliminates the benefits of having a salt, right?

          Wrong. Anyone who can get your encrypted passwords, can get the salt, too.

          > Doing a brute force attack is then possible for "shorter" passwords as the attack adds in your salt for every try at matching the hash.

          Salts have never prevented brute-force attacks. They prevent large sets of precomputed hashes (i.e. "rainbow tables") from reversing your password hashes in seconds.

          > Explain again, how exposing your salt is NOT a big deal?

          Because someone knowing the salt STILL needs to recompute the hashes of all possible passwords, appended onto the salt.

  9. By Chris (198.163.128.1) on

    I don't understand the merit of going HTTPS only. (Having it be possible is nice though.) This will kill access for some older non-updatable devices I have.

    If you're going to downvote, please explain why HTTPS-only is necessary. Something more compelling than paranoid content-swapping stories please.

    Comments
    1. By Anonymous Coward (188.29.31.236) on

      > I don't understand the merit of going HTTPS only. (Having it be possible is nice though.) This will kill access for some older non-updatable devices I have.
      >
      > If you're going to downvote, please explain why HTTPS-only is necessary. Something more compelling than paranoid content-swapping stories please.

      Driving up the cost of wholesale surveillance ?

      Eating our own dog food ?

    2. By ED Fochler (74.106.249.116) obj@liquidbinary.com on

      > I don't understand the merit of going HTTPS only. (Having it be possible is nice though.) This will kill access for some older non-updatable devices I have.
      >
      > If you're going to downvote, please explain why HTTPS-only is necessary. Something more compelling than paranoid content-swapping stories please.

      The problem is that html / http lacks a signature mechanism. We should be able to sign web sites without having to encrypt them just like we can do with SMIME e-mail. This would allow maximum access and verifiability. ... So the real solution to this problem is to re-do HTTP to include a TLS signature appended to plaintext content.

  10. By Anonymous Coward (108.34.251.230) on

    A) what happened with the Perl Rewrite?

    B) can the whole setup not just be put behind relayd? If i recall, its more than capable of serving the whole site behind tls, in addition to supporting the www/auth split for those who want to use http.

    Comments
    1. By Anonymous Coward (108.34.251.230) on

      > A) what happened with the Perl Rewrite?
      >
      > B) can the whole setup not just be put behind relayd? If i recall, its more than capable of serving the whole site behind tls, in addition to supporting the www/auth split for those who want to use http.

      Re: A) overlooked the first comment - but thats funny reply to it, because the perl rewrite was given to me as a reason to not bother hacking on undeadly a couple years ago when it was -still- broken (errata (further funny because undeadly was given as the reason that openbsd shouldn't maintain an rss/or-anything errata feed), search, etc)

      Comments
      1. By Anonymous Coward (108.34.251.230) on

        Wow, don't comment when drunk. I think i've mis-read every post here. My sincerest apologies for the noise

        down vote this away....

  11. By Anonymous Coward (93.115.95.216) on

    Please don't let the few dumb people in the comments discourage this very logical decision.

    Besides the points already made by other posters I would much prefer that for example me making this comment is kept between me and the undeadly sysadmins and that noone in-between us can see exactly what is going on.

    Comments
    1. By Anonymous Coward (198.163.128.1) on

      > Please don't let the few dumb people in the comments discourage this very logical decision.
      >
      > Besides the points already made by other posters I would much prefer that for example me making this comment is kept between me and the undeadly sysadmins and that noone in-between us can see exactly what is going on.

      *Only* serving HTTPS is not necessary for what you want.

      Comments
      1. By Anonymous Coward (185.100.87.82) on

        > > Please don't let the few dumb people in the comments discourage this very logical decision.
        > >
        > > Besides the points already made by other posters I would much prefer that for example me making this comment is kept between me and the undeadly sysadmins and that noone in-between us can see exactly what is going on.
        >
        > *Only* serving HTTPS is not necessary for what you want.

        Yeah I wasn't clear enough in my post, but if the options are only 1 or the other I'd much prefer HTTPS.

  12. By Anonymous Coward (93.104.32.73) on

    So now someone can pledge() it. :-) I looked a little at the code. I'm a mediocre programmer and an even worse reader of others code, I gotta give it to you, that code is good. Small KNF violations though.

  13. By Anonymous Coward (66.249.81.141) on

    If at all possible, please keep an http version available as well. Just as a matter of free information principal.

  14. By foo (151.67.77.113) on

    make undeadly accessible only on an OpenSSH tunnel

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]