The Infosec Thread: Yes, time to move off Entrust

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off Entrust

«‹›507 »

Raenir Salazar: Nov 5, 2010; College Slice

Would this be a good thread to ask about how WW2 era cipher machines worked? I'm not understanding how a half-rotor results in only 1 of 26 output key lamps lighting up.

Additionally there's aspects of a half-rotor I'm not sure of, are they only 13 positions? I'm looking at the Computer Security & Cryptography book by Alan Konheim page 193 of the textbook (213 of the pdf?).

In it, assuming Y in the left part of the rotor is wired to the D on the right side of the rotor; then Y->D->J based off of alignment with the Output plate.

However I don't understand what happens if you press a key not listed in the half-rotor, such as O, I or P. Additionally the pdf does say " Twenty-six wires connect pairs of contacts; one on the the rotor�s left lateral face (LLF) to one on the rotor�s right lateral face (RLF)" so does the rotor have 13 positions or 26? Or is it only happens to display 13 of 26 (In which case what makes it a "half-rotor" compared to a normal rotor?)

fig a.

fig b.

substitution table, formula given below.

fig c.

The substitution table is a little confusing, was the example they gave where pressing Y results in J when i = 21? That would make sense to me if hitting Y again results in I if it results in the rotor turning.

But then if the rotor is set to position 0, and I hit "I" on the keyboard, "O" should light up. And I'm not sure how it accomplishes that. Because "I" is is not listed on the Left side of the rotor, and "O" is not on the Output plate.

Or is only half the letters on the rotor actually being listed for brevity and all 26 are there? In which case what makes it a "half" rotor?

e: Looking at the table and assuming that they're only showing half of the labelled letters and there actually is 26 spots on the rotor, where i==21.

1. Press "I".
2. I is wired to "I" on the left hand side of the rotor. Which is somewhere in the 6 o'clock part of the rotor.
3. The rotor seems to have all the wirings offset by 5 positions, so on the right hand side "I" connects to "N" which is somewhere 8 o'clock.
4. Since U and A are aligned, "N" is -7 positions from U, which means its 7 spaces from A. A - 7 is T.
5. "I" where i=21 does appear to be t.

Do I have this right or am I loving up somewhere, if I do have it right, why is this only a "half" rotor or am I confusing something?

Raenir Salazar fucked around with this message at 00:02 on Apr 17, 2020

# ? Apr 16, 2020 23:40

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:54

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

droll posted:

My boss was saying that our VPN service doesn't work correctly in China when our employees fly there for business trips, even with a 'full tunnel' because the protocols being used are still detectable and the Chinese will block certain types of traffic running over our VPN. Does that make sense?

It's most likely your vpn is being blocked because it makes no attempt to hide the fact it's a vpn connection, not because of what you're trying to do inside it

Although there is also evidence to support the GFW blocking e.g. TLS connections which appear to be carrying a second TLS connection inside, based on packet sizes

Last I heard you could avoid the GFW by roaming with a foreign sim card and using its data. Alternatively the meek pluggable transport + Azure domain fronting option in Tor supposedly still works.

# ? Apr 17, 2020 00:22

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

droll posted:

My boss was saying that our VPN service doesn't work correctly in China when our employees fly there for business trips, even with a 'full tunnel' because the protocols being used are still detectable and the Chinese will block certain types of traffic running over our VPN. Does that make sense? I don't know how to google/what to read to understand this better. I envisaged an encrypted tunnel meant everything in it was just garbage to someone trying to listen.

Try Wireguard I guess. It's UDP traffic that looks pretty much like noise from the get-go, since you're using already set up public keys.

# ? Apr 17, 2020 00:26

droll: Jan 9, 2020; by Azathoth

Wow thank you for all the replies and suggestions. I wasn't directly involved back when this was being tested but apparently the VPN client in full tunnel mode was connected OK but still some traffic was being stopped e.g. access to G Suite but other traffic was not. I don't quite understand my bosses protocol idea though, because G Suite is accessed over HTTPS, so why would one web app be blocked but another was not? DNS? It's always DNS?

I think part of the problem is we didn't have someone from the Information Technology team over there, instead our sysadmin was trying to help a non-technical worker figure it out while reviewing logs on this side.

It's not a problem I've been tasked to solve though, I just asked him about it because of the chat y'all had earlier about packet size and frequency being measured to 'listen' to what might be sent.

droll fucked around with this message at 02:09 on Apr 17, 2020

# ? Apr 17, 2020 02:05

Raymond T. Racing: Jun 11, 2019

Raenir Salazar posted:

Would this be a good thread to ask about how WW2 era cipher machines worked? I'm not understanding how a half-rotor results in only 1 of 26 output key lamps lighting up.

Additionally there's aspects of a half-rotor I'm not sure of, are they only 13 positions? I'm looking at the Computer Security & Cryptography book by Alan Konheim page 193 of the textbook (213 of the pdf?).

In it, assuming Y in the left part of the rotor is wired to the D on the right side of the rotor; then Y->D->J based off of alignment with the Output plate.

However I don't understand what happens if you press a key not listed in the half-rotor, such as O, I or P. Additionally the pdf does say " Twenty-six wires connect pairs of contacts; one on the the rotor’s left lateral face (LLF) to one on the rotor’s right lateral face (RLF)" so does the rotor have 13 positions or 26? Or is it only happens to display 13 of 26 (In which case what makes it a "half-rotor" compared to a normal rotor?)

fig a.

fig b.

substitution table, formula given below.

fig c.

The substitution table is a little confusing, was the example they gave where pressing Y results in J when i = 21? That would make sense to me if hitting Y again results in I if it results in the rotor turning.

But then if the rotor is set to position 0, and I hit "I" on the keyboard, "O" should light up. And I'm not sure how it accomplishes that. Because "I" is is not listed on the Left side of the rotor, and "O" is not on the Output plate.

Or is only half the letters on the rotor actually being listed for brevity and all 26 are there? In which case what makes it a "half" rotor?

e: Looking at the table and assuming that they're only showing half of the labelled letters and there actually is 26 spots on the rotor, where i==21.

1. Press "I".
2. I is wired to "I" on the left hand side of the rotor. Which is somewhere in the 6 o'clock part of the rotor.
3. The rotor seems to have all the wirings offset by 5 positions, so on the right hand side "I" connects to "N" which is somewhere 8 o'clock.
4. Since U and A are aligned, "N" is -7 positions from U, which means its 7 spaces from A. A - 7 is T.
5. "I" where i=21 does appear to be t.

Do I have this right or am I loving up somewhere, if I do have it right, why is this only a "half" rotor or am I confusing something?

There only being 13 letters is just for brevity otherwise they wouldn't be able to fit all 26 lines between the rotor on the left and the right.

# ? Apr 17, 2020 03:26

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

droll posted:

Wow thank you for all the replies and suggestions. I wasn't directly involved back when this was being tested but apparently the VPN client in full tunnel mode was connected OK but still some traffic was being stopped e.g. access to G Suite but other traffic was not. I don't quite understand my bosses protocol idea though, because G Suite is accessed over HTTPS, so why would one web app be blocked but another was not? DNS? It's always DNS?

I think part of the problem is we didn't have someone from the Information Technology team over there, instead our sysadmin was trying to help a non-technical worker figure it out while reviewing logs on this side.

It's not a problem I've been tasked to solve though, I just asked him about it because of the chat y'all had earlier about packet size and frequency being measured to 'listen' to what might be sent.

Is it correctly tunneling your DNS as well? It sounds like said non technical worker may have just been bypassing the VPN, either on purpose or by accident.

# ? Apr 17, 2020 04:21

horse_ebookmarklet: Oct 6, 2003; can I play too?

This is stupid, but how do I SHA-1 a string without writing it to disk? Linux or osx.

I want to check passwords against have I been pwned. I have the database downloaded and have the mighty tool 'grep'.
I don't want to call a binary with the password as an argument, this will get logged in bash history.
I don't want to write it to a disk then call a binary against the file, again hitting the disk.

Is there an easy way to do this? Or should I write a small C app to read from stdin.

# ? Apr 17, 2020 05:54

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

set +o history

# ? Apr 17, 2020 06:02

Raenir Salazar: Nov 5, 2010; College Slice

Buff Hardback posted:

There only being 13 letters is just for brevity otherwise they wouldn't be able to fit all 26 lines between the rotor on the left and the right.

Thanks, that's helpful. For the Japanese "Red" cipher machine, I'm not quite sure how there being 60 contacts works with the rotor. Presumably its 60 contacts from the input keyboard/plugboard to the sliprings connecting to the rotor; does the actual rotor itself have only 26 inputs or does it have 60 inputs but 26 outputs? And it is just cleverly wired so that vowels when the rotor turns only ever map to vowels and consonants only ever map to consonants? In the PDF it gives like, the algorithm for determining the output, but *mechanically* I am curious as to how it does this. How are they going from 26 input keys, to 60 contacts, back to 26 outputs?

# ? Apr 17, 2020 06:02

CLAM DOWN: Feb 13, 2007

horse_ebookmarklet posted:

This is stupid, but how do I SHA-1 a string without writing it to disk? Linux or osx.

I want to check passwords against have I been pwned. I have the database downloaded and have the mighty tool 'grep'.
I don't want to call a binary with the password as an argument, this will get logged in bash history.
I don't want to write it to a disk then call a binary against the file, again hitting the disk.

Is there an easy way to do this? Or should I write a small C app to read from stdin.

Easiest by far is just to clear your bash history.

There's some trickery you can with PowerShell and input streams and .NET calls to do this that I could figure out but it's not worth it. Just clear your bash history.

# ? Apr 17, 2020 06:16

Powered Descent: Jul 13, 2008; We haven't had that spirit here since 1969.

horse_ebookmarklet posted:

This is stupid, but how do I SHA-1 a string without writing it to disk? Linux or osx..

Try this:

code:

echo -n "The string in question" | sha1sum

(The -n means to not include the newline at the end of the string.) You can verify this method against the empty string as shown in the wiki article for SHA-1 as so:

code:

pd@mindworm:~$ echo -n "" | sha1sum
da39a3ee5e6b4b0d3255bfef95601890afd80709  -

Then you may want to delete the command you typed from your local bash history with "history -d" before closing the session, which would write it to the ~/.bash_history file on disk:

code:

pd@mindworm:~$ echo -n "The string in question" | sha1sum
c47a5553bdc795d543b6bd070ccc18e17d114dd7  -
pd@mindworm:~$ history | tail -n 2
  989  echo -n "The string in question" | sha1sum
  990  history | tail -n 2
pd@mindworm:~$ history -d 989

e: The method below saves you a step, just replace the "md5sum" with "sha1sum", or if you're on a Mac, "shasum -a 1". You can still verify this method by giving it an empty string, as above.

Powered Descent fucked around with this message at 06:40 on Apr 17, 2020

# ? Apr 17, 2020 06:25

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

cat | tr -d '\n' | md5sum <enter> yourinput <enter> <ctrl+d>

# ? Apr 17, 2020 06:26

wolrah: May 8, 2006; what?

If you don't want the command to be logged to bash history you can just stick a space before it.

code:

wolrah@box:~$ ping test.com
PING test.com (69.172.200.235) 56(84) bytes of data.
^C
--- test.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1022ms

wolrah@box:~$  ping example.com
PING example.com (93.184.216.34) 56(84) bytes of data.
^C64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=33.9 ms

--- example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.920/33.920/33.920/0.000 ms
wolrah@box:~$ ping cnn.com
PING cnn.com (151.101.129.67) 56(84) bytes of data.
64 bytes from 151.101.129.67 (151.101.129.67): icmp_seq=1 ttl=55 time=31.2 ms
64 bytes from 151.101.129.67 (151.101.129.67): icmp_seq=2 ttl=55 time=30.6 ms
^C
--- cnn.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 30.677/30.980/31.283/0.303 ms
wolrah@box:~$ history
[snip]
 2001  ping test.com
 2002  ping cnn.com
 2003  history
wolrah@box:~$

Notice how the second ping, the example.com one, does not show up in history.

# ? Apr 17, 2020 14:40

Qwan: Jan 3, 2020

wolrah posted:

Saying it's about "compressing then encrypting" is way overbroad, because how else do you propose to compress anything? Lossless compression works on patterns that good encryption will eliminate and lossy compression requires knowledge of the plaintext. Either way it doesn't work to do it after encryption.

---

I'm not really familiar with the details of the CRIME/BREACH stuff but I am intimately familiar with VoIP and related topics. The problem discussed in the UNC paper is not a problem caused by "compressing then encrypting" it's purely choosing the wrong codec for the job. A real-time stream with a variable bit rate inherently leaks information about its content through packet sizes, and encrypting them doesn't change a thing about that.

As noted in the mitigation section of the paper, using a constant bitrate codec without silence suppression eliminates the problem entirely. You're still compressing before encrypting, you're just using the right compression for the job. Padding the data also works but defeats the purpose of using the VBR codec so it doesn't make sense in most cases.

Saying a VBR stream leaks information is utterly meaningless in a vacuum as the stream leaks literally everything. That statement is only meaningful in the context of encryption - and in that context the encryption runs into trouble exactly because the stream was compressed beforehand.

D. Ebdrup posted:

drat, I'm sorry to say I completely loving whiffed on reading your post. Scrolled right past it.

BREACH requires three components, ie, RFC3749 with DEFLATE and querystring or HTTP POST to contain user-data, and part of the secret to be in the HTTP response body if I recall correctly? Which to me makes it sound like a weakness in RFC3749 in particular, and not a fault with the general idea of encrypting data after it's been compressed.
For example, does it apply to TLS1.3 with HTTP Live Streaming or Dynamic Adaptive Streaming over HTTP? Both are compressed video streams, and are used to push a pretty significant chunk of the internets traffic from Youtube and Netflix, including WebRTC and similar stuff used for Zoom, Jitsi, Google Meet/Hangouts, and other similar services.

That paper is a loving rad bit of science - there's something almost cyberpunk about using computational linguistics and speech analysis on phonemes - I'll have to take some time to read it though, since my brain's fried today.
EDIT: The only thing I've gotten from it so far is that it looks to be more about de-anonymizing the person rather than actually decrypting what's being said.
Does it even go into what crypto primitives are being used for the systems?

You two seem to be under the impression that I am claiming that compressing before encrypting always inevitably makes bad things happen. Of course, I am not saying that.
The specific details of all those attacks do not really matter as on a fundamental level we are usually fine with encryption leaking information about the length of the plaintext (e.g. the definition of semantic security basically boiling down to "leaks absolutely nothing - except information about the length of the plaintext"). With the raison d'etre of compression being to mess with the length depending on the content of the message one just has to be very, very careful when compressing before encrypting as modern cryptography just delights in biting you in the rear end when you least expect it.

# ? Apr 17, 2020 16:17

BlankSystemDaemon: Mar 13, 2009

Is that not exactly what you said?

Qwan posted:

Again, if they do "compressing then encrypting" it is an issue.

Qwan posted:

And that you can get in all kinds of hot water by "compressing then encrypting" is kinda well known

# ? Apr 17, 2020 16:45

CLAM DOWN: Feb 13, 2007

wolrah posted:

If you don't want the command to be logged to bash history you can just stick a space before it.

code:

wolrah@box:~$ ping test.com
PING test.com (69.172.200.235) 56(84) bytes of data.
^C
--- test.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1022ms

wolrah@box:~$  ping example.com
PING example.com (93.184.216.34) 56(84) bytes of data.
^C64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=33.9 ms

--- example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.920/33.920/33.920/0.000 ms
wolrah@box:~$ ping cnn.com
PING cnn.com (151.101.129.67) 56(84) bytes of data.
64 bytes from 151.101.129.67 (151.101.129.67): icmp_seq=1 ttl=55 time=31.2 ms
64 bytes from 151.101.129.67 (151.101.129.67): icmp_seq=2 ttl=55 time=30.6 ms
^C
--- cnn.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 30.677/30.980/31.283/0.303 ms
wolrah@box:~$ history
[snip]
 2001  ping test.com
 2002  ping cnn.com
 2003  history
wolrah@box:~$

Notice how the second ping, the example.com one, does not show up in history.

No way, is that a bash feature? Prefixing with a space? I didn't know that, thanks for the tip.

# ? Apr 17, 2020 16:47

Qwan: Jan 3, 2020

D. Ebdrup posted:

Is that not exactly what you said?

quote:

Again, if they do "compressing then encrypting" it is an issue.

In the specific context of VoIP it is well known that compressing (VBR) before encrypting is an issue.

quote:

And that you can get in all kinds of hot water by "compressing then encrypting" is kinda well known
~snip
You two seem to be under the impression that I am claiming that compressing before encrypting always inevitably makes bad things happen. Of course, I am not saying that.

The key word is "can". For aforementioned reasons compressing before encrypting is just structurally a potential source of trouble that one has to keep in mind.

# ? Apr 17, 2020 17:04

BlankSystemDaemon: Mar 13, 2009

CLAM DOWN posted:

No way, is that a bash feature? Prefixing with a space? I didn't know that, thanks for the tip.

It's documented in the man-page, under HISTCONTROL - so I would guess that something needs to set it, possibly a skeleton file or some other sort of distribution-specific feature.
One feature that I wish more shells, including tcsh, would integrate, is the erasedups functionality of HISTCONTROL - it basically deduplicates your history, by deleting previous instances of the same command from your history.

HISTCONTROL being a environment variable is also why you can't rely on history for auditing and need proper BSM-like integration.
I don't know what Linux does for this, but FreeBSD and macOS integrate OpenBSM and FreeBSD even lets you use dtrace with auditd to inspect everything happening on production servers with only 1-2% probe-effect.

# ? Apr 17, 2020 17:13

Hollow Talk: Feb 2, 2014

The cool new thing on Linux is eBPF, which projects like Falco use. There was a cool talk about this at Fosdem this year: https://fosdem.org/2020/schedule/event/kubernetes/

# ? Apr 17, 2020 17:45

Klyith: Aug 3, 2007; GBS Pledge Week

D. Ebdrup posted:

That's an amazingly creative hack!

Actually using it as an attack seems extremely unlikely -- they show slightly different voltages needed for different CPU models, when it varies by individual processor. This is like the inverse of extreme overclocking, and it's well known that each CPU varies a bit for what voltage/frequency combinations are stable.

So I think the idea that this could be an offline attack as they present:
1. collect info about target's software and CPU model
2. design an attack against that software and CPU using a different CPU of the same model
3. deploy attack in a single hit
hasn't been demonstrated in the slightest. In particular (my emphasis):

quote:

We evaluated this attack on a Core i7-7700K and a Core i7-8700K processor.

They're attacking the physical nature of the CPU, and they show that two different CPUs have different conditions needed (selected voltage, which core is best attacked) for their results. They don't show that their outlined attack method is feasible, and I have to say that it almost feels deliberate that they didn't test multiple CPUs of the same model. Anyone who knows anything about CPU voltage tweaking knows that each processor is very slightly different, while their own data shows that they are targeting down to a 5mV window to get good results.

# ? Apr 17, 2020 17:46

BlankSystemDaemon: Mar 13, 2009

Klyith posted:

That's an amazingly creative hack!

Actually using it as an attack seems extremely unlikely -- they show slightly different voltages needed for different CPU models, when it varies by individual processor. This is like the inverse of extreme overclocking, and it's well known that each CPU varies a bit for what voltage/frequency combinations are stable.

So I think the idea that this could be an offline attack as they present:
1. collect info about target's software and CPU model
2. design an attack against that software and CPU using a different CPU of the same model
3. deploy attack in a single hit
hasn't been demonstrated in the slightest. In particular (my emphasis):

They're attacking the physical nature of the CPU, and they show that two different CPUs have different conditions needed (selected voltage, which core is best attacked) for their results. They don't show that their outlined attack method is feasible, and I have to say that it almost feels deliberate that they didn't test multiple CPUs of the same model. Anyone who knows anything about CPU voltage tweaking knows that each processor is very slightly different, while their own data shows that they are targeting down to a 5mV window to get good results.

The point they're making is that fault injection attacks were previously required to have a physical presence of some sort.
What this attack does is give a deliberately targeting attacker the means to affect fault-injection attacks via software alone.

So the attacks don't scale well but if you're gonna get MOSSAD'd upon then MOSSAD now has an extra tool in its toolbox.

# ? Apr 17, 2020 18:21

Absurd Alhazred: Mar 27, 2010; by Athanatos

https://twitter.com/lizthegrey/status/1251271701352103939

# ? Apr 17, 2020 23:25

Raenir Salazar: Nov 5, 2010; College Slice

Absurd Alhazred posted:

https://twitter.com/lizthegrey/status/1251271701352103939

I don't get it and the tweet chain I'm not really understanding, what's going on here?

# ? Apr 18, 2020 00:01

Absurd Alhazred: Mar 27, 2010; by Athanatos

Raenir Salazar posted:

I don't get it and the tweet chain I'm not really understanding, what's going on here?

Zoom creates a prompt that misleads you into thinking you have to log in with admin user/password to resolve an audio issue when restarting the program would be enough. I'm not sure why she's backpedaling, just because they didn't hack OSX but OSX instead just allows the app to write arbitrary words and icons on the prompt doesn't mean it's not horrible practice on their end.

https://twitter.com/radoshi/status/1251277156425977857

# ? Apr 18, 2020 00:30

Lambert: Apr 15, 2018; by Fluffdaddy; Fallen Rib

I love the fact that the "OS X" branding has stuck, even though apple only used it for a pretty short time.

# ? Apr 18, 2020 00:38

Mantle: May 15, 2004

They called it OS X for 11 years.

# ? Apr 18, 2020 03:54

Lambert: Apr 15, 2018; by Fluffdaddy; Fallen Rib

Jesus Chroist. Didn't we just use mac os 9??

# ? Apr 18, 2020 08:27

Proteus Jones: Feb 28, 2013

Lambert posted:

Jesus Chroist. Didn't we just use mac os 9??

Hey there, Rip Van Winkle. How was the nap?

# ? Apr 18, 2020 13:31

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Lambert posted:

Jesus Chroist. Didn't we just use mac os 9??

malloc is for chumps

# ? Apr 18, 2020 13:45

BlankSystemDaemon: Mar 13, 2009

The real question is whether you pronounce it X or 10.

# ? Apr 18, 2020 14:54

Mr Chips: Jun 27, 2007; Whose arse do I have to blow smoke up to get rid of this baby?

D. Ebdrup posted:

The real question is whether you pronounce it X or 10.

Mac OS X ten point twelve

# ? Apr 18, 2020 15:59

Powered Descent: Jul 13, 2008; We haven't had that spirit here since 1969.

D. Ebdrup posted:

The real question is whether you pronounce it X or 10.

I had the same question about Mega Man X, back in the day. :corsair:

# ? Apr 18, 2020 17:20

Klyith: Aug 3, 2007; GBS Pledge Week

Anything with an 'X' is pronounced 'ecks' unless it was proceeded by IX, VIII, and so on.

I was gonna write a joke here something like, "What comes after X if you can just use whatever numeral system you want, egyptian hieroglyphs? Is the next apple OS going to be 'OS Ra Eyeball'?" But then I discovered:
a: the egyptian hieroglyphs for 11 is boring ∩|
b: the hieroglyph for "million" or "many" is a guy with his hands in the air 𓁨

"I don't know, I can't count all of those! :shrug:

Just lots."

# ? Apr 18, 2020 18:13

Tobermory: Mar 31, 2011

Question for the goons in this thread:

I'm working on a project with an international non-profit org. One of the things they want is an ability for people to file anonymous whistle-blowing complaints over the web. These complaints could potentially piss off a whole bunch of people, including foreign governments, human traffickers, and organized crime. The application part of this is (relatively) straight-forward, but hosting the application is out of my expertise. Their hosting needs to be secure (so it doesn't get hacked in retaliation) and anonymous (so that the whistleblowers don't get murdered in retaliation).

Does anyone have some suggestions for a really secure, anonymous, online hosting platform? The preference would be for someone that doesn't, for example, log IP addresses; alternately, we'd be fine with a host who would respond to subpoenas by telling a government to gently caress off.

# ? Apr 20, 2020 19:38

EssOEss: Oct 23, 2006; 128-bit approved

If you think your users know how to use Tor, that's pretty much what Tor hidden services are intended for - tracking where a Tor hidden service is hosted is impractical, as is tracking who accesses it. Instead of hosting providers having to say "no", your hosting provider will simply not be identifiable (and nor will your users). Requires your users to use a Tor-capable browser, though, which would certainly reduce the set of users who you can serve.

For regular web usage, "bulletproof hosting" is the general term used to refer to hosting providers who tell complaint submitters to gently caress off. Governments can be harder to persuade to go away but possibly a strategic choice of jurisdiction for the hosting provider could help. However, I can make no specific recommendation and one should consider how seriously one can take the providers' claims.

# ? Apr 20, 2020 20:04

Wiggly Wayne DDS: Sep 11, 2010

securedrop was made for this purpose, consult them for implementation details

# ? Apr 20, 2020 20:10

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

Tobermory posted:

The application part of this is (relatively) straight-forward,

It really isn't, use securedrop

# ? Apr 20, 2020 20:16

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Rufus Ping posted:

It really isn't, use securedrop

Woah are you suggesting that they do not roll their own crypto?

# ? Apr 20, 2020 20:19

evil_bunnY: Apr 2, 2003

Tobermory posted:

I'm working on a project with an international non-profit org. One of the things they want is an ability for people to file anonymous whistle-blowing complaints over the web. These complaints could potentially piss off a whole bunch of people, including foreign governments, human traffickers, and organized crime. The application part of this is (relatively) straight-forward

If you think that, you're quite probably in over your head. Securedrop has been pointed out to you and that's what I'd use in your situation

# ? Apr 20, 2020 20:34

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:54

Tobermory: Mar 31, 2011

Thanks, everyone. I'll steer them in the direction of Securedrop.

# ? Apr 20, 2020 21:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off Entrust

«‹›507 »