What exactly is the difference between kill <pid> and kill -s TERM <pid>.
Initially i thought the $TERM variable holds a signal number but when I echo TERM its gives me
$echo $TERM
xterm-256color
The OP has often seen variables being assigned without a $, and CAPS indicating variables, so they thought that kill -s TERM is passing the variable TERM.
2
I find that both funny and entirely understandable!
@terdon If you are not able to review something, then do NOT review it. Do not reject it with made-up reasons. Let the author of the answer or people familiar with the matter do it. Discouraging people from correcting misinformation in highly upvoted answers (which are the only ones that people coming here from searches read) is plain disgusting. Especially when coming from a moderator. No, I AM NOT THE AUTHOR of that edit suggestion neither affiliated with him or her in any way.
@user431397 rewriting other people's answers is not a technical question. If the answer is dangerous or misleading and obsolete then a disclaimer/warning on top might help readers from getting trapped.
@user431397 Woah there. Relax. I was perfectly capable of reviewing it, thank you. And it was a very, very extensive edit, changing the answer significantly. Such edits are regularly rejected, because substantial changes like that to an existing answer circumvents the quality control process of the site (voting) and that's why it is better to post a new answer instead of rewriting an existing one.
However, the main reason I rejected it is that it was essentially a complete re-write of the answer. It kept the quote that was in the original, and the odd preposition and just about nothing else:
There was a remark in the edit comment about a previous version "perverting" the answer or something like that. If that's the case a rollback might be called-for.
If you are saying that we should allow edits that completely subvert the intent of the original answer, I would disagree, but that's something for meta.
If this answer is obsoleted/misleading/does not provide a useful solution to the title question today — which I don't know about — there is literally nothing to do about it and it will be left there to lead people astray forever
No, a new answer can be posted (answers are sorted by "active first" by default, apart from the accepted, so new answers would still be visible). If the new answer is right, it can be voted up.
Can someone help me understand how a client accepts a certificate presented by a server? The server has the certificate, and when the client connects to the server, the server shows that certificate to the client. How then does the client know if the certificate is valid or not? I think a private key is involved somewhere but I'm not sure how it is used in the interaction between the client and server.
@MichaelHomer but then the single point of failure is the quality of the person rewriting the answer. With a warning the original intent is there, but readers can think "OK, I need to investigate what I should do, let me look at the other answers"
So while I agree that technically it's more against author's intent to say their answer is useless, from a usability and knowledge repository standpoint it's the lesser wrong
@BlackPanther If this is TLS, the certificate chain presented will lead to a root (digitally signed along the way) that is preemptively trusted by the client. The operating system or browser comes with a fairly large set of root certificates that it trusts and any certificate that it accepts is signed by a certificate that's signed by a certificate ... that's in that store
It work because last line self sign certificate, note when used as https: //192.168.1.3/foo any browser will complain about certificate being untrustworthy.
@MichaelHomer that really is a shame, because I miss your excellent and informative answers. Your constant passive aggressive attacks on the community I could do without.
@MichaelHomer Thanks for looking at that answer. The Certificate authority in that example is localhost. Is the certificate authority the same as the root authority you mention?
@terdon There's nothing passive about them. A small number of persistently abusive users drove me away, as you well know, and at a few points in the last year or so we have also seen the indefensibly repugnant behaviour of large swathes of users across the network, with whom I would not wish to associate
I stand by all of the aggression on both of those points and it is quite direct.
@MichaelHomer Great! So because the server's certificate is signed by the certificate authority in the browser, that certificate authority can vouch for/validate the certificate is legitimate. Is this how the interaction between the server and browser works when a certificate authority is imported to the browser and the server the browser connects to has a certificate signed by the certificate authority?
@BlackPanther The CA has signed (transitively) the server's certificate, claiming that it knows the certificate belongs to who it says it belongs to. The certificate corresponds to the private key stored on the server, and between the public (certificate) & private keys the server and client can verify that the server is in possession of the private key, the public key has been asserted by the CA to belong to some particular entity (domain name), and thus that the server is controlled by that entity
@Archemar Thanks. In that answer there are two keys, myCA.key and $NAME.key. What is the difference between these two keys? It looks like only myCA.key is used to sign the certificate at the end, but I'm not sure.
The CA has a public-private key pair, and the server certificate also has a public-private pair
The CA signs other people's certificates with its private key so that the signatures can be verified with its public key
Since there is only one customer here, that private key only gets used once, but you could for example sign further certificates with it
The customer public key is signed by the CA and that's the certificate distributed to clients. The customer private key is used in the exchange process to verify that you are talking to the other half of that public key
Is the customer the creator of the private key which was used to create the following certificate signing request? `openssl req -new -key $NAME.key -out $NAME.csr`
The CA signs other people's certificates with its private key, and other people validate those using its public key. Something similar happens with the customer's two keys to authenticate the TLS connection
@BlackPanther I was distinguishing three roles: CA (root), customer (e.g. server), and client (e.g. browser). The customer would be the one making the CSR, yes
@BlackPanther The certificate that's distributed in the TLS handshake contains the public key and the signature(s) on it, so I was a bit sloppy conflating them exactly
@MichaelHomer I don't understand how the customer's private key is used in the exchange process to verify that you are talking to the other half of it's paired public key?
There are two paths: historically, the client generated a random number, encrypted that with the public key, then sent it to the server. The server would decrypt it with the private key, and so they both had that number to use to encrypt all the traffic (and so if they're successfully communicating, it has to have been decrypted correctly)
@MichaelHomer I'm thinking of the CA's public-private key pair as a witness-committer pair. I can't think of a better word for committer right now. But any way, my reasoning is that the committer (i.e. the private key) signs the public key in the customer's certificate, and the witness is the only one other than the committer, who knows what the signature looks like.
Better, they use Diffie-Helman exchange for a session key, which means the transaction has forward secrecy, and the authentication exchange isn't used for the actual transmission encryption
For the CA, it generates a hash of the customer's certificate details, decrypts that with its private key, and attaches that to the certificate
The client gets the certificate and the signature, encrypts it with the public key, and verifies that the hash of the actual certificate details matches the result of the encryption
(signing and encryption are dual in RSA)
There are other crypto systems that work slightly differently, but that's the general idea of it
@BlackPanther It's preferred to use D-H secret exchange to set the session key so that a later compromise of the private key doesn't allow decrypting the transmissions
The authentication is more a side effect of the encryption exchange in the most basic version of my "historic" path there, but in reality there is always a separate authentication phase since very early on. That can work the same way (generate random data, encrypt it, get the other side to send it back to you in plaintext), but also some more complex ones
@MichaelHomer that fits my naive mental model that public keys are padlocks and private keys are, well, keys. You can give people your padlock which they can use to lock stuff, and you can prove to them that the padlock is yours by opening the lock and revealing the contents.
(All of this has been substantially simplified - there are several different cryptographic algorithms, different TLS versions, different kinds of key exchange, all of which could still be in use today - your example is generating RSA keys, but it wouldn't have to be)
The "proof" case would more often be signatures, which is the reverse of the example I gave: I send you a nonce value, you sign it (which is actually the decryption operation) and send it back, then I verify it (by encrypting with the public key) to check
@MichaelHomer Thanks. Would you know how to combine the customer's private key with a certificate? Dotnet only allows me to send a single file to Kestrel so I cannot supply both the private key and public key separately.
Can I just concatenate the .crt and $NAME.key to get a .pem file?
RSA (Rivest–Shamir–Adleman) is a public-key cryptosystem that is widely used for secure data transmission. It is also one of the oldest. The acronym RSA comes from the surnames of Ron Rivest, Adi Shamir, and Leonard Adleman, who publicly described the algorithm in 1977. An equivalent system was developed secretly, in 1973 at GCHQ (the British signals intelligence agency), by the English mathematician Clifford Cocks. That system was declassified in 1997.In a public-key cryptosystem, the encryption key is public and distinct from the decryption key, which is kept secret (private).
An RSA user...
Actually, I think I know why the association bonus is a flat rate. Some Stack exchange sites are easier to gain rep on than others, so someone from a totally unrelated field to software engineering could sign up to stack overflow, and carry over their really high rep.
They may seem like an expert due to their rep, but they're actually not.
Most specifically, I hate that featured company posts on MSE get upvotes from MSE-inactive users but not downvotes. Biases perception of important posts a lot.
But yeah, SO has always been the flagship site, and the company is thinking about cutting off non-tech sites (at least smaller ones) if they can pull it off
@BlackPanther Also, you might find just reading the high-level overview of TLS from Wikipedia useful if you're interested in that sort of detail. It's not really relevant to using TLS that someone already implemented, though
Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.
The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. When secured by TLS, connections between a client...
There are 13 listed steps involved (though some are a bit minimal and some could be split up)
@MichaelHomer I want to give a very simplified summary of what I learned from you about the certificate exchange between a (localhost) server and a client. Please point out any wholes in my understanding:
The CA has a public-private key, so does the certificate. The CA's private key signs the certificates public key, and the CA's public key witnesses this signing process so that it can verify it later. The client connects to the Server, the Server's certificate is presented to the client, and the private key of the certificate is used by the CA's private key to authenticate the public key of the certificate that is paired to the certificates private key.
Hence the client accepts the Server's certificate as legitimate.
The private key of the certificate is used to prove that the server the client is talking to is the owner of the certificate. That is a separate decision than whether the certificate is validly attested by the CA
@MichaelHomer This answers what I was going to ask: But what is the server's (i.e. certificate's) private key used for then? I mean it's a separate entity so why give it to the server in the first place?
@MichaelHomer If the public key of the CA verifies the signature. Then why is the private key of the certificate (i.e. the server's certificate) needed to verify the owner of the certificate, isn't this already accomplished by the CA's public key?