@mentallurg So, to argue a solution is "more secure" you have to explain all of the security features which are being used to provide that increase in security. Simply saying "I put a self-signed CA cert in a file" achieves nothing, because how do you know what's in there is trustworthy? What could cause some other solution -- say, just using SSH and verifying manually that the SSH crypto is correct -- to be less secure? You've not done that.

@JulieinAustin: Do you mean applications on both servers should use SSH to exchange the public key?

But to use SSH, you would need to provide each server with credentials for another server. And as public key authentication.

For this authentication, you would need first to put corresponding public keys on each server.

Thus, to enable both server to trust each other you would first put there public keys to .ssh dir of each one.

In my opinion, this is similar task as asked in the OP, but done once more on another level

Thus this makes the solution x2 complex.

Now suppose you have mutually shared their public keys for SSH. Now you need to implement the logic in the application to talk to each other via SSH. I find it pretty hard task.

Suppose application A puts via SSH the data that need to be exchanged with application B on another server (OP wants to exchange public key). But how will B know that there is some data to pick up? B will have to implement kind of polling. Then how will A know that B has received the data? B should send some response. To read it, A will have to do polling.

I find it VERY complex.

Compare it to a communication via HTTP (REST service, Servlet or similar): A call service on B and posts needed data (public key). B receives it and reacts correspondingly. Also B immediately returns a response. Standard communication via HTTP. No need to invent any exchange protocols.

One more aspect: For SSH (or SCP) each server will contain credentials needed to login on another server. If you control both servers, the risk of misuse will be low, but still not zero. But if you don't use SSH, this risk is zero. Why should one use an approach that has higher risk?

@mentallurg No one said security was easy. At the end of the day you should be able to explain why something is secure, not just say one way was easier than another way.

SUre. If someone asks, I can explain

@mentallurg You've yet to explain how me how this is *secure*.

But I suppose many people have similar understanding to mine and similar assumptions that I implicitly have done and that you actually named and made them explicit :)

OK, what exactly would you like me to explain?

@mentallurg - My background is formal operating system security evaluations. I'm asking you hard questions because you're smart.

:) thanks.

@mentallurg The question I asked originally: How do you know, in a security-sense, that the certificate on the server is the certificate which you self-signed in the first place? What's the chain of trust? How do you verify that back to something?

I saw you profile, you have a solid experience, so I don't doubt

I'm on Stack Overflow looking up all the options to do this very thing :)

There needs to be an openssl command called "DO EVERYTHING YOU STUPID COMMAND!"

:)

to your question - how to verify

sure, everything what is done needs to be tested or verified, need to be audited regularly etc

in case of certificates my approach would be following:

I generate a certificate on a system I consider as secure

then I calculate a fingerprint of certificate

and write it down or store

Yeah, the reason CAs are such a powerful concept is you can hard-code things like certificate signatures in applications. This got sort of funky with storing certs in files which are potentially mutable, without making sure they weren't mutated.

then I transfer certificate to the target server, add it to the directory with CA certificates or to trust store file

then I check that this directory or trust store contains this certificate . If contains, I check its fingerprint

compare to previously noted one

if matches - this is THE certificate that I have generated and that I wanted to put there

Done

How do you know the certificate is the same one week after next?

How do the servers mutually know they aren't talking to a certificate which was replaced?

server with a ... certificate ...

first, I start with evaluation of the risks

what is the price if certificate is replaced/forged?

what does it harm?

does it prevent me from just viewing non-secret logs?

then it makes sense to ignore such risks

in the worst case just replace certificate

other case is if compromised certifcate costs 100 000 000$

then completele different procedures would be used

I would not use self signed certifcate

I would not do that alone

yeah, that's the "CA root certificate has been compromised". that's why some certs are kept completely off-line in locked vaults.

there shpould should be at least 2 persons needed to perform such operation

there are strict auditing rules needed

there are tools needed that check the integrity of different system file including those with certificates

there are crypto algorithms where N of M people are needed -- if you get that far into your career look into them. people die. don't bet the company on people not dying. they'll disappoint.

e.g. one need to make sure that the kernel was not modified etc

right - databases with secure hashes of system-critical files.

those can be compiled into read-only objects stored in inaccessible -- at least DAC-protected -- parts of system storage.

but when we look at the kind of the question, we can assume - with high probability - that actually not so high security is actually required.

if CA is not used (at least an internal CA), then the price of possible security risks is low

... or the risks are just not (yet) recognized :)

people can be lulled into a false sense of security. my approach would be similar as yours, but I'd had a cert which had a well-known signature, then ensure that signature was in the chain.

for serious purposes noone would look for such a solution

Oops. wrong paste buffer!

cs.cmu.edu/~rdriley/487/papers/…

:)

yeah, that's a CA+CERT i'm working on generating. i have another hardware solution i'm going to use, but that's the initial software one.

OK, I'll read it later. The first sentences bring already questions

it is well known, that there is no way to prove that a programm works in particular way

the key is to make implicit assumptions explicit -- what is the threat environment? what attacks aren't defended against? i jumped in because if it had been me, in a reasonably secure hardware environment, i'd have just used SSH and made a self-signed CA cert, signed a server cert, and been done.

why should one discuss it one again?

correct, and what Ken Thompson was saying is that we really don't have a way of knowing. if you don't recognize the name, he was an inventor of UNIX, along with Dennis Ritchie and Brian Kernigahn. that was Ken's Turing Award paper. it's required reading where your career will likely take you.

I know Ritchie and Kernigan :)

"made a self-signed CA cert, signed a server cert, and been done" - this part is exactly as I suggested

I think the author did not realized that CA certificates of Comodo, VerySign & Co are also self-signed certifcates.

... and that actually - technically - there is not difference between our self-signed certificates and thos of VerySign

the only difference ist that their certificates are preinstalled everywhere and thus trusted by everyone, where as our (yours, mine) are rtusted only locally

yes, but if it mattered i'd have also made sure the certificate wasn't modified, or i'd have been explicit. remember the original question -- "Without a trust root of some sort which can be externally verified, "just copy the files" achieves nothing. Because now what you have is "How do I copy my certificates with someone who didn't just do all that and replace yours with theirs?""

may be this idea was unexpected to some users

they are also well known

that's their other real value -- you can get the signature of their certificates off of many bathroom walls, no doubt.

yes, but I think not everyone understands it deeply

:)

i'd agree with that. i also think a lot of people don't understand the value of "well-known CA root certificate signatures."

yes

and the risks behind this

one of the key concepts is ways to bootstrap from a small piece of information -- say, a very big secure hash -- to an assurance that the entire system is presently functioning in a "secure state", however that "secure state" has been defined.

because when we get such CA certificates pre-installed on outr systems, we really TRUST in the common sense (not in the IT / PKI sense)

have no choice - i have to lietrally TRUST that VerySign stores its private key securely and that NSA, FBI, CIA, Mossad, FSB & Co have no private key

and not so many people think how actually fragile it is

yes, but a lot of people don't grasp that "trust" is actual a negative -- we're "critical dependent" on that thing. we can't just go "Oh, Julie is smart, I trust her." i used to work for 1Password, and i wrote the section on one of their white papers on why we could trust their DBA not to steal things. so, i liked the guy, and i hope to see him again some day, but in that "security" sense, i don't trust him.

yes - that's critical. understanding the fragility of it all. because it's a house of cards, as we learned through variation "Secure Hash Algorithms" not being all that secure

MD5?

MD5 isn't as bad as some which came before it! but also, various SHA's.

i have 30+ years of security background. there was life before MD5, SHA256, AES-256.

cool

I am actually workign in software development, not security

security is kind of hobby

I was one analyzing custom encryption of one of customers

and found it was 3DES with custom MAC

the worst - it was self made, not compatible with standards

nobody cared

kind of "If nobody understands what is going on, we are secure"

yipes!

yeah, this was my third evaluated O/S - commoncriteriaportal.org/files/epfiles/0194a.pdf

that's the "we don't play" kind of security.

if you want a really nice dive into how a secure product was designed, this is a good read -- 1password.com/security/#security-white-paper. i don't know if anything i wrote is still in there. if you want to go further in security, they are a great company to work for, if you can handle working remote, which i couldn't.

i ran their bug bounty when i was there. the top bounty was $100K.

wel it has many facets. E.g. how do we know there are no backdoors "by design"?

for instance, some leackage of information, bit by bit over time

as a person I have no means to check it

bugcrowd.com/agilebits

only organisations with a huge budget can do that