I'm using the Policy autosigning in the Open-source puppet to get it run an executable before deciding whether to sign a certificate (https://docs.puppetlabs.com/puppet/latest/reference/ssl_autosign.html#policy-based-autosigning). Our executable queries an external webservice and converts the result for puppet to use. This is worked fine, but assumes the executable's result is static.
The issue is if a host turns up and isn't instantly signed, Puppet never seems to check with the executable when the host turns up again - it remembers the previous result and doesn't sign the certificate.
Is there a way of getting puppet to call the executable every time an unsigned host attempts to get it's certificate signed, rather than just once?
Related
ERROR: Registering runner... failed
runner=J4DBd8we
status=couldn't execute POST against https://tarun-labs.local/api/v4/runners:
Post https://tarun-labs.local/api/v4/runners: x509:
certificate signed by unknown authority PANIC:
Failed to register this runner
Hi I am facing same problem and tried searching many forums for answers and didn't got any solution yet. config.toml file location is not clear as the one I saw is not the right one I think It is in /gitlab-runner folder and shows only 3 parameters: [Concurrent][check Interval] and [Session Server]. So now way I can change any Value. As I am registering the runner ..the [runners] tab is not expected to be there.
I am trying this on home lab therefore do we need a "single" self signed certificate or need to have CA Certificate as well. Not clear [Full Chain ? or only CA+Server Cert]. I am using home lab so cannot arrange certificate from Pubic CA.
Also is there a way I can skip this error by bypassing SSL? I have seen tls verify or ssl verify option to be set to no.. Where to put that is not clear or mentioned in any forum whatsoever.
This should be common problem for many as fresh installation does not give you any runner to begin with so everyone should be doing these steps. Please help anyone?
From gitlab documentation.
GitLab Runner reads the PEM certificate (DER format is not supported) from a predefined file:
1 - /etc/gitlab-runner/certs/hostname.crt on *nix systems when GitLab Runner is executed as root.
2 - ~/.gitlab-runner/certs/hostname.crt on *nix systems when GitLab Runner is executed as non-root.
3 - ./certs/hostname.crt on other systems. If running Runner as a Windows service, this will not work. Use the last option instead.
If your server address is: https://my.gitlab.server.com:8443/, create the certificate file at: /etc/gitlab-runner/certs/my.gitlab.server.com.crt. To verify that the file looks correct, you can use a tool like openssl.
I have a PHP application, with Usernames and Public SSH Keys in it. I would like to use these accounts as the user back end of openssh.
I think I need to use pam_exec and a PHP/Bash script. I've written a php script that I can execute at CLI (The shebang sets an env of php executable). If I need to wrap this in a bash script instead to access environment variables I can do that. The script currently takes a username as its first and only parameter like so:
/opt/scripts/my-auth-script.php user_to_look_for
The script will exit zero on success (the user exists) or exit 1 if not. It currently echoes OK or Failed also but I can easily turn that off.
So, my question is, how do I have pam_exec call my script to look for user accounts, before looking on the actual host system for user accounts?
I've got it working. The way to do this is to set the AuthorizedKeysCommand and AuthorisedKeyUser settings of openssh in sshd_config. There is a caveat, the reason that github and others provide ssh as a service through a single login user shared among customers is that the user being called must be resolvable by the system being logged into, so they muxt exist locally, or the user db must be connected to a remote source like LDAP, which would also then have to be integrated into the application.
The way to get around this though, is that the AuthorizedKeyCommand can take parameters, %u for username, and also in this case %k for key or %f for sha256 fingerprint of the key. Then, that script can ignore the generic username it was given, and then just check the database for a match for the key or fingerprint. If we find it, we have the user for that key and successful authentication. If not we dont.
I am interested in an in-depth answer explaining how exactly X11 authorization works and especially MIT Magic Cookies.
I understand that what it actually does is to forbid access to everyone else except the user that is logged in, also there are some control mechanisms that control whether a client application can connect to an X display server or not.
I also found that there are five standard access control mechanisms and they can be categorized in three main categories:
Access based on host
Access based on cookie
Access based on user
But from this point and on I don't really understand the way these work and what ways they exactly use in order to do the authorizations.
Well, first of all there is a file ~/.Xauthority on the machine.
Notice that (usually on machine with GUI) wrong permissions of this file, can cause a login screen loop... (took me hours to understand that).
As you mentioned there are 5 mechanisms:
Host access: the server has host access list (if a network address exists in this list, the connection is permitted). the list is managed using xhost command. NOTE: this doesn't allow more than a single connection simultaneously. I don't know more about this method because I don't really used it. but you can see man Xserver GRANTING ACCESS section :)
MIT-magic-cookie-1: Generating 128bit of key ("cookie"), storing it in ~/.Xauthority (or where XAUTHORITY envvar points to). The client sends it to server plain! the server checks whether it has a copy of this "cookie" and if so, the connection is permitted. the key is generated by DMX.
XDM-authorization-1: Again, there is a key stored in ~/.Xauthority. this key consists 2 parts- 56bit DES encryption key and 64bits of random data used as the authenticator.
When you connect to the server the client generate 192bits of data: ctime combined with 48bits identifier (for tcp/ip: ip address+port, for local connections it's the PID and 32 bit unique id). the DES key is used to encrypt the data and then it is sent to server. the server validate the user by decrypting it then validating the 64bits authenticator and additional data.
sun-des-1: it uses asymmetric encryption, the server has a public key which he uses to decrypt incomming requests. it also uses the "host list". This require some additional mechanisms in the network, I don't have such network so again, I don't understand this mechanism well.
server interpreted: It can be implemented in so many ways... but in general, the client send 2 string to server. The second string is the user entry (such as username) and the first string is the entry type (such as localuser).
NOTE: the 2nd, 3rd and 4th mechanisms store the keys inside ~/.Xauthority therefore anyone who has access to this file, can connect to the server pretending to be "you".
xauth command can parse Xauthority file and extract the interesting values.
$ xauth
Using authority file /home/ME/.Xauthority
xauth> list
ME/unix:10 MIT-MAGIC-COOKIE-1 5e443c146376d0bdadfd712bfe7654be
ME/unix:0 MIT-MAGIC-COOKIE-1 c48ddba801384dce3aaaa9d442931ea12
xauth> info
Authority file: /home/ME/.Xauthority
File new: no
File locked: no
Number of entries: 2
Changes honored: yes
Changes made: no
Current input: (stdin):2
xauth>
The data is changed....
I'm developing a POS Client using Chrome (packaged) Apps. It will run locally on the installed computers and interact with the server via web service. This app should only run on specific computers at the stores.
I know I can go to each store and install the .crx file in which case I don't have to publish the app to Chrome Web Store. However, I want it to be published to Chrome Web Store so that I can take advantage of its auto-updating feature.
What should I do to make sure that the app can only run at the stores' computers? (I can go the the stores and setup anything needed at the first installation).
Options I have thought of:
Create some secret key and enter it to the app at the first time of running.
Build a small tool (winforms application) to generate time-based tokens and install it on the computers. The staff will need to enter the token each time opening the app.
Any better idea how to accomplish this?
You said the app needs to talk to a web service to work. That's the key to a simple approach. (Assume you don't care whether the staff acquires a nonfunctional copy of the client app.)
At startup, app checks for existence of a validation of some kind stored in chrome.storage.local. If it exists, startup continues.
If the validation is missing, the app checks for existence of a GUID stored in chrome.storage.local.
If the GUID is missing, generate and store one using something like window.crypto.getRandomValues().
Ask the server for a validation by sending the GUID and getting a response.
If a validation comes back, save it in chrome.storage.local and go back to the start of this sequence.
Otherwise tell the user to get lost.
A full-strength version of this approach would have some additional features:
Use an HMAC(GUID, secret) for the validation. I'm assuming the staff aren't tech superstars, so something simple like a boolean would probably suffice.
Optionally add a per-launch step that sends up the GUID and validation and confirms it's still valid each time.
When the validation is requested, you might prompt for the secret key you mentioned in your question. In normal cases this would be needed only at provisioning time.
In case you haven't figured it out yet, the server is now acting like a simple licensing server, so it's up to you to decide how to decide whether the validation request succeeds. Maybe it allows only N validations to exist at once, or after you're done provisioning you hardcode future validations to fail. Maybe it limits validation requests to certain IP addresses. You get to choose.
That's the gist. It's a simple DRM system that is easier to manage than the enter-secret-at-installation method, but that won't withstand an attack of more than 30 minutes (since a smart attacker will just inject another machine's GUID and HMAC validation into the duplicate machine's chrome.storage.local).
I want to ensure that client libraries (currently in Python, Ruby, PHP, Java, and .NET) are configured correctly and failing appropriately when SSL certificates are invalid. Shmatikov's paper, The Most Dangerous Code in the World:
Validating SSL Certiļ¬cates in Non-Browser Software, reveals how confusing SSL validation is so I want to thoroughly test the possible failures.
Based on research a certificate is invalid if:
It is used before its activation date
It is used after its expiry date
It has been revoked
Certificate hostnames don't match the site hostname
Certificate chain does not contain a trusted certificate authority
Ideally, I think I would have one test case for each of the invalid cases. To that end I am currently testing an HTTP site accessed over HTTPS, which leads to a failure that I can verify in a test like so:
self.assertRaises(SSLHandshakeError, lambda: api.call_to_unmatched_hostname())
This is incomplete (only covering one case) and potentially wrong, so...
How can you test that non-browser software properly validates SSL certificates?
First off, you'll need a collection of SSL certificates, where each has just one thing wrong with it. You can generate these using the openssl command line tool. Of course, you can't sign them with a trusted root CA. You will need to use your own CA. To make this validate correctly, you'll need to install your CA certificate in the client libraries. You can do this in Java, for example, using the control panel.
Once you have the certificates, you can use the "openssl s_server" tool to serve an SSL socket using each one. I suggest you put one certificate on each port.
You now have to use the client library to connect to a port, and verify that you get the correct error message.
I know that Python by default does no certificate validation (look at the manual for httplib.HTTPSConnection). However, m2crypto does do validation. Java by default does do validation. I don't know about other languages.
Some other cases you could test:
1) Wildcard host names.
2) Certificate chaining. I know there was a bug in old browsers where if you had a certificate A signed by the root, A could then sign B, and B would appear valid. SSL is supposed to stop this by having flags on certificates, and A would not have the "can sign" flag. However, this was not verified in some old browsers.
Good luck! I'd be interested to hear how you get on.
Paul
Certificate hostnames don't match the site hostname
This is probably the easiest to check, and failure (to fail) there is certainly a good indication that something is wrong. Most certificates for well-known services only use host names for their identity, not IP addresses. If, instead of asking for https://www.google.com/, you ask for https://173.194.67.99/ (for example) and it works, there's something wrong.
For the other ones, you may want to generate your own test CA.
Certificate chain does not contain a trusted certificate authority
You can generate a test certificate using your test CA (or a self-signed certificate), but let the default system CA list be used for the verification. Your test client should fail to verify that certificate.
It is used before its activation date, It is used after its expiry date
You can generate test certificates using your test CA, with notBefore/notAfter dates that make the current date invalid. Then, use your test CA as a trusted CA for the verification: your test client should fail to validate the certificate because of the dates.
It has been revoked
This one is probably the hardest to set up, depending on how revocation is published. Again, generate some test certificates that you've revoked immediately, using your own test CA.
Some tools expect to be configured with a set of CRL files next to the set of trusted CAs. This requires some setup for the test itself, but very little online setup: this is probably the easiest. You can also set up a local online revocation repository, e.g. using CRL distribution points or OCSP.
PKI testing can be more complex than that more generally. A full test suite would require a fairly good understanding of the specifications (RFC 5280). Indeed, you may need to check the dates for all intermediate certificates, as well as various attributes for each certificate in the chain (e.g. key usage, basic constraints, ...).
In general, client libraries separate the verification process into two operations: verifying that the certificate is trusted (the PKI part) and verifying that it was issued to the entity you want to connect to (the host name verification part). This is certainly due to the fact these are specified in different documents (RFC 3280/5280 and RFC 2818/6125, respectively).
From a practical point of view, the first two points to check when using an SSL library are:
What happens when you connect to a known host, but with a different identifier for which the certificate isn't valid (such as its IP address instead of the host)?
What happens when you connect to a certificate that you know cannot be verified by any default set of trusted anchors (for example, a self-signed certificate or from your own CA).
Failure to connect/verify should happen in both cases. If it all works, short of implementing a full PKI test suite (which require a certain expertise), it's often the case that you need to check the documentation of that SSL library to see how these verifications can be turned on.
Bugs aside, a fair number of problems mentioned in this paper are due to the fact that some library implementations have made the assumption that it was up to their users to know what they were doing, whereas most of their users seem to have made the assumption that the library was doing the right thing by default. (In fact, even when the library is doing the right thing by default, there is certainly no shortage of programmers who just want to get rid of the error message, even if it makes their application insecure.)
I would seem fair to say that making sure the verification features are turned on would be sufficient in most cases.
As for the status of a few existing implementations:
Python: there was a change between Python 2.x and Python 3.x. The ssl module of Python 3.2 has a match_hostname method that Python 2.7 doesn't have. urllib.request.urlopen in Python 3.2 also has an option to configure CA files, which its Python 2.7 equivalent doesn't have. (This being said, if it's not set, verification won't occur. I'm not sure about the host name verification.)
Java: verification is turned on by default for both PKI and host name for HttpsUrlConnection, but not for the host name when using SSLSocket directly, unless you're using Java 7 and you've configure its SSLParameters using setEndpointIdentificationAlgorithm("HTTPS") (for example).
PHP: as far as I'm aware, fopen("https://.../") won't perform any verification at all.