Obfuscate logs? Before including in help topic?

Before entering a question, I’m looking for guidance on whether to obfuscate any information in a letsencrypt debug log before including it in the question.

If this guidance is not currently documented on community.letsencrypt.org may I suggest that it be included. Perhaps at the start on entering a new topic a line about removing sensitive information such as …, or don’t worry about including logs there aren’t any private keys in the log.

I don’t particularly want to include .conf files which are contained in the debug log as they give some small measure of comfort to potential crackers by revealing directory structure… That’s a pretty small worry though, but EFF promotes security…

a log obfuscator tool might be useful?

1 Like

Security by obscurity is no security.

2 Likes

Hi @jhalbrecht,

For the most part, we think the information that Certbot logs in /var/log/letsencrypt isn’t too sensitive to share publicly. Sometimes people are worried about the various numeric identifiers that appear in these logs, but none of those are private keys, and none of them are credentials that could be used without the corresponding private keys to cause certificate misissuance or otherwise impersonate a site. One example is challenge file contents, which people sometimes don’t want to share because their meaning is totally unclear and they look a lot like encryption keys (but they aren’t; they’re just random numbers which are designated by the CA for a one-time use in the context of a specific certificate request).

I know it’s a lot of information, and it’s information whose sensitivity is unclear, but I think we should probably focus on removing certain information from the logs because it’s rarely useful for debugging rather than because it’s too sensitive. (I think there’s information that could be removed for this reason, although I don’t have a specific example offhand.)

On the forum we’ve always had a lot of trouble with people not providing enough information to help the forum participants diagnose and debug problems, especially in cases where there was a DNS or firewall misconfiguration, or where the exact Let’s Encrypt error messages explained what went wrong but the users didn’t share them. I think the people answering questions on the forum are going to continue to be concerned that people asking for help are almost always sharing too little information, not too much.

Starting next month (after I leave EFF), I’m going to be available for paid support where I can help people completely privately, for a fee (so their domain names and configuration information wouldn’t be published anywhere). I hope that other people or businesses will offer similar services so that people who don’t want to share the kind of information that the forms ask for, or don’t want to share their full logs or configuration files, will still have somewhere to turn. But it’s often really important for the detailed information to be shared with someone, either with the public on the forum or with a consultant elsewhere. We don’t want to make the people who are trying to help guess about what the nature of the problem is when there are already detailed logs that would resolve that question.

If you do see specific pieces of data in your logs that you think shouldn’t be there because they’re especially sensitive or especially irrelevant for debugging, assuming you’re using Certbot, I think the Certbot team would be receptive to making changes to how that particular data is logged.

7 Likes

If this guidance is not currently documented on community.letsencrypt.org may I suggest that it be included. Perhaps at the start on entering a new topic a line about removing sensitive information such as …, or don’t worry about including logs there aren’t any private keys in the log.

Thanks @schoen condense it a bit and put it in a FAQ that new forum users will see. And enough SEO to expose it outside this forum.

The more troubling information I noticed in the debug log was apparently a copy of the site .conf files, possibly exposing weaknesses to potential crackers

1 Like

There is a second motivation for obscuring the domain: to stop polluting the search engine results for the domain name. This forum ranks extremely high on search engines. I would be surprised if even half of posters asking for help knew about this hidden punishment waiting for them, at the time that they post their threads.

For my own Let’s Encrypt-related business I have a shell script that I ask users to run when they ask for support, which encrypts and sends me pretty much everything I need to diagnose problems. This was created because I got really tired of non-conformance with instructions or people just not being familiar enough with a terminal. Granted, it’s not directly useful for a forum/community context.

The way we ask for information in the help template really suffers from a lot of problems (SEO, non-conformance and also that being able to wrap code blocks in Discourse basically requires you to be a huge nerd), though it may be the least worse solution. I have long dreamt about reviving the abandoned letshelp idea that the Certbot project had, but that it could basically package all the common diagnostic information up, upload it to an unindexed storage website where the user could review what information was available, and redact or delete it at their own discretion. But it would harm discoverability for other users suffering from the same issue so I don’t really know where the best middle ground is …

5 Likes

I was just about to post some questions about pastebin. I was trying to find the netiquette regarding the use of a pastebin site to include logs here on the letsencrypt community. I didn't find any if it exists.May we use pastebin? I see a lot of posts using them...

@_az If this forum ran it's own pastebin then that pastebin could be not indexed, while the question could be.

It's sure a lot easier to read a long file from a pastebin than it is inline in a question in this letsencrypt community forum.

1 Like

I saw a user get told off once by a staff member for hiding their domain inside a spoiler tag, so the choices they have made about asking the user to include the information in the post are probably quite deliberate. The poster is ultimately empowered - you can use a pastebin if you want, and the discoverability/permanence of the post will suffer, but it’s up to you.

1 Like

Why was that, do you remember?

1 Like

This was the post. Sorry @schoen :stuck_out_tongue: .

1 Like

I think we could rethink that in light of the observations that you made above. I think we felt fairly clear on that back then but there might be a middle ground, like “if you’re particularly concerned about people finding the domain name with a search engine, you can use the spoiler tag”. … However, a relevant preliminary question might be whether that will actually succeed in hiding the domain name from a search engine or not!

1 Like

Why don’t we try putting two randomly chosen words abkajh oijqwoirj that currently don’t have any Google results inside a spoiler tag here, waiting a few days, and then searching for them again on Google?

2 Likes

@schoen As those words are literally in the HTML code, I’m pretty sure it would be picked up by Google. Unless Google also parses CSS code from class tags et cetera.

3 Likes

Yeah, that seems likely. I wasn’t sure if it was going to be substituted into the DOM by Javascript or something. :frowning: (indeed, it’s not)

2 Likes

Also, search engines like Google do execute the Javascript, so it's not enough, but you can ask them nicely to not index a part of a page with "googleoff" like in https://github.com/letsencrypt/website/blob/master/layouts/_default/single.html#L20

Docs: https://support.google.com/gsa/answer/6329153?hl=en#82542

3 Likes

But that won’t have any effect on Bink or DuckDuckGo I assume.

3 Likes

As expected from @Osiris’s observations, Google now shows this page as a hit for a search including the two random words that I hid with a spoiler tag. So we can confirm that that method wouldn’t help with this concern.

6 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.