Sciencemadness Discussion Board - Securing Sciencemadness: understanding the threat model

Securing Sciencemadness: understanding the threat model

Polverone - 24-7-2013 at 12:41

<A HREF="http://www.chemicalforums.com/index.php?topic=38535.0">Why does my browser give a warning when I use the HTTPS version of Sciencemadness?</A>

This site offers secure communications over HTTPS to protect members from dragnet surveillance operated by rogue governments working hand-in-glove with paid or cowed providers of Internet backbones and exchanges. For this purpose I use a self-signed SSL certificate, refreshed yearly. Every time I refresh the certificate your web browser will complain that the secure connection is not trusted, because my self-signed certificate is not approved by any known certificate authority. <b>My use of self-signed certificates is intentional. I do not need more money so I can buy a certificate that major browsers will accept without prompting.</b> If I obtained a SSL certificate from a recognized certificate authority, the provider would know the secret key and could be pressured to turn it over to a government agency. This was once just a theoretical risk, but it appears to be more than theoretical now:

http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-...

I encourage all registered members and regular lurkers to use the HTTPS version of the site. There is an unfortunate historical legacy in how browsers treat communications security: maybe-insecure connections based on HTTPS with unknown certificates raise prominent warnings, while definitely-insecure HTTP connections are accepted without a peep.

There are additional risks: this site runs from a data center in California. Law enforcement or other government snoops with California jurisdiction could request a copy of the private key retrieved from the hosting provider's backups. Or just get everything in the backups, including U2U messages and web server logs. Many companies cooperate even without being served with a warrant. I do not know if this is true of my own hosting provider. In the event that a warrant were served, it could have a gag order attached, so I would never know what had happened. If you want your U2U messages secured, use PGP.

Different threat models have different appropriate responses. If I were running a bank, I would want to use a SSL certificate issued by a known authority rather than a self-signed certificate. That might make communications more vulnerable to dragnet surveillance, but it would better protect against the threat of imitation by garden variety thieves. People do not use Sciencemadness to store or transfer money, so the threat from dragnet surveillance is more relevant than the threat of an imposter site set up to steal credentials.

I have considered and so far rejected going HTTPS-only. The additional server load from going HTTPS-only would be minor. That's not an issue. As watson said, encryption only increases suspicion if it distinguishes you from the crowd. If SM were always encrypted there would be nothing special about one visitor's traffic over another. Maybe it distinguishes SM as a site from others that don't use encryption -- well, fine. I think that the vast majority of material read and written on this site is OK for public consumption. I consider it a civic service to help normalize the use of encryption even when people don't "need" it, because I believe it is technologically feasible and socially desirable to diminish the value of dragnet Internet surveillance.

The site security is only useful against incidental dragnet surveillance and nosy neighbors on shared wifi, not against secret courts armed with secret orders. When I last used a very rarely used email account to update the site domain registration, there was an almost year old inquiry from (apparently) an FBI agent working on foreign intelligence. It didn't say anything but "get in touch with me" and I didn't bother to follow up. For all I know he went to the courts and there has been a secret tap on this site for months. In the past persons claiming to be law enforcement from Singapore have asked for information about members; they were also ignored and the members were alerted. I won't give up information without a court order, but since the server isn't located in my house I'm probably not even going to know that a court order exists.

[Edited on 7-25-2013 by Polverone]

papaya - 24-7-2013 at 13:53

I've heard somewhere in this forum that the engine used for this site is rather old, so is it possible in theory that there may be known vulnurabilities that are exploited at server side to gain access to any needed information? I mean - is this site maintained with applying every bugfixes and updates, how is the situation overall?

AndersHoveland - 24-7-2013 at 18:20

I do not understand how these keys work? Can they not just be intercepted by the service provider?

I am assuming you are not referring to public key encryption.

Polverone - 24-7-2013 at 20:04

Papaya, it is possible that there are vulnerabilities in the XMB forum software, or elsewhere. For example, a couple of members recently reported that there was a security problem with how members could upload scripts through the scipics FTP, so I have disabled uploads until I can get Apache to disable scripts in that directory tree. I have kept XMB up to date as new versions are released, but it has been years since a new release or even since the last vulnerability I needed to patch. This forum software does not have as many features as others but in its ossified state it is also unlikely to develop new exploitable bugs.

Anders, I am talking about public key encryption. SSL uses public key encryption to transfer the small symmetric keys that are used for bulk data encryption. The current site SSL certificate uses 2048 bit RSA. The company that operates the server that Sciencemadness runs on could capture the key without anyone noticing by taking it from a disk snapshot or regular backup. But they could not capture the private key from the network traffic, because it stays on the server. Neither can your internet service provider, a person sharing your wifi connection, or government agencies capture the private key just by intercepting your network traffic. This is what makes SSL secure against snoops and more ordinary criminals who have not subverted the communication endpoints.

papaya - 25-7-2013 at 03:10

What about sslstrip?

watson.fawkes - 25-7-2013 at 04:47

Quote: Originally posted by papaya

What about sslstrip?

That's an active attack, not a passive one. That attack requires an active intermediary, not one that can only monitor traffic. The difference is that passive attacks cannot in principle be detected but active attacks can be. This is a significant point if the opponent would suffer political consequences from discovery, say, a law enforcement agency conducting an unauthorized intervention.

Trying to protect against every threat model is letting the best be the enemy of the good. SSL is a perfectly decent (though not decently perfect) mechanism against the most common threats. It's Polverone's call about what threat model he's protecting against.

All of which leads me to a question for Polverone. What are the downsides of disabling cleartext HTTP traffic entirely and presenting only the SSL interface? Years ago, it was poor browser implementations that would have created a de facto barrier to SSL access, but that's no longer true. Do there remain any other reasons to retain cleartext access?

woelen - 25-7-2013 at 05:15

HTTPS can introduce a heavy load on the server. Setting up HTTPS-sessions requires a fair amount of cryptography at the server side. Once a session is established, then the amount of computational load is not that high anymore, but it is the initial setup which may be killing your server if the server is busy. I have the impression that sciencemadness is not a really busy forum, but the CPU load introduced by a lot of HTTPS session setup cryptography must certainly be considered before it is decided to put everyone on HTTPS.

Besides the performance issues mentioned above I see no reason to allow HTTP access anymore, although on the other hand, I also do not really care about this for a site like sciencemadness. It is a public site, so everybody can read anyway what I write on this site and if some agency wants my private communication (U2U), then they simply enforce the owner of this site to give that information.

froot - 25-7-2013 at 06:07

The more you try conceal yourself the more of a curiosity you become.

I'm a bit of a dummy when it comes to internet handshake protocols but if I understand this correct, HTTPS will prevent surveillance of your activities only while you're browsing right? Anything you leave behind such as posts on the forum can be read by anyone provided that forum's public permissions are set accordingly. So the only advantage they have while I'm using HTTP is being able to monitor my browsing activity only while I'm online.
So if I'm using HTTPS they can only do what they seem to be quite good at, assuming I'm up to no good and act on these assumptions.
I'm just concerned that concealing this site's activities, or even attempting to do so, and considering some of it's content, would give them the reasoning they were hoping for to win an order to have the site shut down which would really spoil my day.

woelen - 25-7-2013 at 06:36

The only things which really are secured by use of HTTPS are the references section, whimsy and personal U2U's. These cannot be read by other people after they are produced, unless Polverone provides access to them.

watson.fawkes - 25-7-2013 at 07:23

Quote: Originally posted by froot

The more you try conceal yourself the more of a curiosity you become.

That's true only if your behavior is different than others. If the only way to use the board is SSL, then using SSL provides zero information about users.

Quote: Originally posted by woelen

Setting up HTTPS-sessions requires a fair amount of cryptography at the server side.

A decade of Moore's law has greatly diminished the effect of this load. CPU capacity has increased faster than disk speed and network bandwidth, so I can't imagine it's the same problem it used to be.

Quote: Originally posted by woelen

The only things which really are secured by use of HTTPS are the references section, whimsy and personal U2U's.

Not only that. It also protects knowing what's being read. Not everyone reads the whole board, so it removes inference of interest based on reading patterns.

ElectroWin - 25-7-2013 at 08:36

Quote: Originally posted by froot

The more you try conceal yourself the more of a curiosity you become.

this argument worked before Snowden reminded us what liberties various governments are taking. regardless, however, i never write anything on this board that i wouldnt say to public.
So my use of SSL is mainly to confound nosey neighbours.

Polverone - 25-7-2013 at 11:17

The additional server load from going HTTPS-only would be minor. That's not an issue. As watson said, encryption only increases suspicion if it distinguishes you from the crowd. If SM were always encrypted there would be nothing special about one visitor's traffic over another. Maybe it distinguishes SM as a site from others that don't use encryption -- well, fine. I think that the vast majority of material read and written on this site is OK for public consumption. I consider it a civic service to help normalize the use of encryption even when people don't "need" it, because I believe it is technologically feasible and socially desirable to diminish the value of dragnet Internet surveillance.

I allow plain HTTP because popular machine translation services will not handle HTTPS connections, or at least did not the last time I checked. I can see from server logs that a fair number of lurkers read this site through machine translation, as I have read some German and Russian chemistry forums through translation.

There is an additional issue if I were to switch over: I would need to intercept every visit to an old unsecured url (e.g. http://www.sciencemadness.org/talk/viewthread.php?tid=25296) and rewrite it to the /whisper/ version. There are quite a few external links to the site, so just automatically fixing up forum posts isn't an option.

mr.crow - 6-8-2013 at 06:57

Many web services use HTTPS, and some are HTTPS only. Any website with a login form should use it. There is a great tool that can enable these for you HTTPS Everywhere

I believe someone from Google said it had minimal impact on their server load. If you think about websites it would be mostly disk and network traffic not CPU load.

Since this is a public forum there is nothing wrong with having regular HTTP, except for loggging in. I am happy there is an HTTPS option.

Rosco Bodine - 12-10-2013 at 09:19

The SSL connection is not working.

Semmelweis - 12-10-2013 at 10:25

I'd like to note that, by having both http and https versions, everything Google turns up on SM is repeated. Search something like "sciencemadness diethyl ether" and the first two results will be to the same thread, albeit the first to the http version and the other to the https. This kinda pollutes the search results, while also biasing visitors towards the http version (which is probably linked more often from other sites).
Maybe changing something in robots.txt or messing with Google, to choose which version appears in the search results, would be nice.

Polverone - 12-10-2013 at 14:42

Rosco, can you elaborate on SSL not working? It appears to be working for me. The certificate shouldn't need to be refreshed until next month.

Rosco Bodine - 13-10-2013 at 00:04

It isn't a certificate warning issue, it simply won't connect in explorer, while other https sites still will connect okay. It still works in firefox, but not in IE8 in XP. Could be a browser issue. It just stopped connecting.

bfesser - 13-10-2013 at 09:22

I suspect that it is indeed a browser issue. It's been working fine on everything I've been connecting with.

On a related note; I'm thinking of writing a script or modification that will replace protocol-specific links within the forum. It's damn annoying when people post links to other topics that switch the protocol.

Tip: The best way to link to another topic is to use HTML (BBCode won't work for partial URLs), as shown:

Code:

<a href="viewthread.php?tid=25296">Securing Sciencemadness: understanding the threat model</a>

Semmelweis - 13-10-2013 at 12:48

Wow, there are no restrictions to using HTML links here?
This seems to pose a great security risk, since it allows one to create links that execute arbitrary Javascript code when clicked.
e.g.

Code:


<a href="#" onclick="alert('Javascript! Oh the humanity')">Click to create textbox!</a>

The code above:

<a href="#" onclick="alert('Javascript! Oh the humanity')">Click to create textbox!</a>

It's trivial to replace the textbox code, with others with malicious intent, like stealing forum login cookies!
This should be disallowed!

bfesser - 13-10-2013 at 14:28

No, it shouldn't. I keep an eye out for malicious links and remove/disable them. It's really more of a risk to the client, and if someone's dumb enough to click on anything they see without checking it, that's their own problem. Any half-competent internet user has script blocking and other security measures in place, anyway. As long as none of the moderators or administrator's accounts are compromised, it's not much of a threat to the site.

BBCode is so crippled that it's essentially useless, without HTML to make up for it, the fora would be a very bleak plaintext wasteland.

Polverone - 13-10-2013 at 15:06

Quote: Originally posted by Rosco Bodine

It isn't a certificate warning issue, it simply won't connect in explorer, while other https sites still will connect okay. It still works in firefox, but not in IE8 in XP. Could be a browser issue. It just stopped connecting.

A couple of months ago I updated the SSL configuration to reject weak ciphers and promote cipher suites that enable perfect forward secrecy. I may have made the available cipher suites too restrictive -- I tested with several browsers, but not IE. I have updated the configuration to allow additional cipher suites, and I was just able to visit the site with IE 6 in secure mode. Please try again now.

Why did I enable perfect forward secrecy and reject weak ciphers? Basically, PFS means that even if someone manages to steal or decrypt the private key for the SSL certificate, it is still hard to decrypt individual sessions that may have been recorded by e.g. Internet backbone taps or wifi snooping. Rejecting weak ciphers means that subtle manipulation of your session cannot be used to force your communications into a low-security mode that an attacker could easily decrypt.

Semmelweis - 13-10-2013 at 16:08

Quote: Originally posted by bfesser

No, it shouldn't. I keep an eye out for malicious links and remove/disable them. It's really more of a risk to the client, and if someone's dumb enough to click on anything they see without checking it, that's their own problem.

You go around manually checking the HTML of every link you see? If you do, most people do not, for obvious reasons.

Also, while script blocking is indeed an intelligent security measure, most people don't enable it everywhere by default, among other reasons for being such an annoyance, since most sites use javascript nowadays. I guess many have not enabled it here.

Unless every single piece of HTML is checked, you can not be sure if it will be safe, since it can fail silently (i.e. work normally for an user with script blocking, steal info from one without).

Code injection is a very solid threat.

While I agree BBCode is relatively weak, many (most?) forums do not have HTML enabled, since it's so easy to misuse.

As a compromise, maybe HTML should be filtered, removing dangerous attributes like "onclick". Or maybe it should not be allowed for everyone.

Or maybe not. I am new here, and this forum is very well established and well managed (I have been lurking around for quite some time, love this place). If you feel it's okay to keep it, then keep it. Just wanted to share some ideas on security.

Edit: Also, if you think BBCode is crippled, note that it can be extended.
More info: http://www.vbulletin.org/forum/showthread.php?t=68184

[Edited on 14-10-2013 by Semmelweis]

bfesser - 13-10-2013 at 17:33

I'm aware that BBCode can be extended—Polverone added the [sub] and [sup] tags that I coded—but the board software is a lost cause. I think that we should focus efforts on <a href="viewthread.php?tid=18651">migrating to greener pastures</a>.* I agree that it's a threat, but I just don't think it's worth the effort to patch. The threat should be resolved when we migrate.

*You seem knowledgeable on this subject. Care to pitch in? I've been procrastinating on it for far too long, and Polverone's simply too busy. If you're interested, respond in the other topic.

Semmelweis - 13-10-2013 at 18:20

I do know a decent amount of Javascript and HTML. Started learning long ago, when I only had IE6, a 56Kbps modem connection and a book about general informatics my uncle gave me. I don't know much php/SQL, through I have seen it, and it seems easy (fast) to learn. Recently I wrote a C++ program to create statistics from Skype's message history (stored in an SQL db file).

When I have the opportunity i will surely reply to that topic. Currently, I have some severe studyng to be done (should be, already). I also have to get some space freed on the ol' faithful 80GB IDE disk. "One will be glad to be of service", if I do get to help in the conversion.

bfesser - 14-10-2013 at 06:55

Great; it sounds like you're at the same level of incompetence as I am—knowing just enough to get yourself into trouble.

Marvin - 14-10-2013 at 11:33

I accepted the certificate but I still get warnings and hoops to jump in Chrome, it says "Server's certificate does not match the URL". I wasn't going to mention it but if the certificate is being fiddled with anyway

SHA-256 Fingerprint 81 41 E0 45 57 2C 95 8A C4 34 3C 44 DC 38 2D 5D
BB A4 72 B9 3E E8 38 D2 7B 1C 21 55 30 D2 8C 3C

bfesser - 16-10-2013 at 09:47

I didn't want to start a new topic for this; but I wonder if anyone else has noticed that the server time appears to be off by maybe two or three minutes (ahead).

Compare my system time to the "posted on" timestamp above.
12:44:30 CST

[edit] I'm also CST, but have to set EST in my profile to get the correct hour...
[2nd edit] GMT? Seriously? This forum software is beyond hope.

[Edited on 16.10.13 by bfesser]

Polverone - 16-10-2013 at 14:55

I will try to get a better matching certificate when I next regenerate it.

Quote: Originally posted by bfesser

I didn't want to start a new topic for this; but I wonder if anyone else has noticed that the server time appears to be off by maybe two or three minutes (ahead).

Compare my system time to the "posted on" timestamp above.
12:44:30 CST

[edit] I'm also CST, but have to set EST in my profile to get the correct hour...
[2nd edit] GMT? Seriously? This forum software is beyond hope.

[Edited on 16.10.13 by bfesser]

The forum software does not appear to handle daylight savings time correctly. It shows non-DST times year round. I added a cron job for daily NTP synchronization. The server previously got the value once at boot time but would then drift until the next reboot, which could be many months.

bfesser - 16-10-2013 at 15:11

Alright, thanks for the clarification, <strong>Polverone</strong>. I noticed while posting earlier that my own computer's NTP synchronization doesn't seem to be working properly. I'm going to have to look into fixing it. Goddamn Linux Mint... it's 2013 and they can't even get the clock right‽ It's downright ridiculous. This is why Windows die-hards think Linux is a joke. Oh well, at least I don't have to fight with USB drivers.

Crowbar - 26-5-2015 at 03:25

Hey Polverone,

First, your server still accepts some weak ciphers. See https://www.ssllabs.com/ssltest/analyze.html?d=sciencemadnes...
It's also reporting an issue with PFS.
Furthermore, there are other server settings that affect security. An ultra-concise reference that includes recommended configs for the common web servers: https://cipherli.st/

Second, when your next annual self-signed certificate reissue time rolls around, how does anyone of us know we're not being man-in-themiddled and that the new certificate actually comes from you?
Consider providing some out-of-band method for us to verifying the site's new certificates, such as publishing a hash of the key on multiple other channels.
Alternately, sign the site certificates with a root certificate you create, and publish the root (and revocation list) elsewhere. Setting up is just a few openssl commands, and it has the important benefit that the root key can be kept off the hosted site machine: you only use it on your own secure system to sign the site certificates.

In general, I don't see why you reissue your certificates annually. The only idea I have is if you intend to use this as a warrant canary in case you're gagged by a national security letter. Which also begs the question of why you'd use a US-based host in the first place. Numerous companies and organizations with far tamer content than this site have moved their data elsewhere. It may be the cautious thing to do to follow suit.

WangleSpong5000 - 2-3-2019 at 18:55

Bump

I'm learning a lot in this thread about net security, I'm a self taught web dev student who studies the front end a tad more than the back. I must say though I completely disagree when it comes to drawing ones attention to one self by using heightened levels of security. I use a VPN everytime i log on (almost) on principle. It's a matter of Liberty which to me is more important than almost everything. But I digress... it appears phpBB version 3.2 has vulnrabilties just as the older versions had. SQL injection is still an issue to a lesser extent as is cross script attacks... I have much to learn on the subject but I would like to test out the new site regardless... with the Admins permission of course.

katyushaslab - 19-1-2021 at 18:58

So I work as a security consultant in my day job most of the time. If the owners/admins would like any help with securing the forum, threat modelling, etc, I'd be more than happy to lend my time freely.

Edit:
If there is a way to send like, a VM/container or other "copy" of the SM setup with a dummy database as opposed to the actual user data, this could tie in with the "forum modernisation" thread.

As it stands, in 2021, there is no reason to not enforce SSL/TLS. SSL/TLS is now the default for the internet. Encrypted web traffic is no longer the standout - its the norm.

[Edited on 20-1-2021 by katyushaslab]