crocs-muni / usable-cert-validation Goto Github PK

Get rid of the extensive number of useless blank lines.

...and archive the old one to x509errors.cz/devconf2018.

Based on Petr's paper

On the website, in the error list, there's "the project GitHub" links. Clicking on them results in 404.

One example is https://github.com/crocs-muni/usable-cert-validation/tree/master/errors/X509_%C2%ADV_%C2%ADERR_%C2%ADCERT_%C2%ADNOT_%C2%ADYET_%C2%ADVALID.

If you look closely, they contain %C2%AD which is "SOFT HYPHEN" Unicode character.

• Migrate files.
• Rename user -> endpoint.
• Add Makefile with variables.
• Clean config templates.

Currently, the "rolldowns" with details about various errors cannot be expanded without JavaScript enabled, which makes the page somewhat less usable.

One solution would be to use the <details> and <summary> HTML5 elements, although they are not universally supported.

Another solution, in the spirit of progressive enhancement and unobtrusive JavaScript, the rolldowns could be expanded by default and only collapsed upon page load in browsers that run scripts.

Write example code performing TLS connection in OpenSSL and incorporate it in the repo.

• Include Google Tag Manager with events on individual error boxes.
• Create a dashboard with the overview of main events.

To reflect changes in the OpenSSL documentation, parse and generate the original .pod file with the documentation: https://github.com/openssl/openssl/blob/master/doc/man1/openssl-verify.pod

Currently, the archives contain many files (certificates, keys, CSRs, expected outputs). Certificates would be sufficient.
Secondly, the folder structure in the archive can be much simpler (just the error case folder).

First step: Consult Matej Grabovsky (PA193 experiment).

If it's really duplicity, submit a merge request to update the one with less info.

Don't build the web on GitHub servers – build on Travis instead and just push generated files to GitHub (the same way faktaoklimatu.cz does). This way, local plugins can be used.

• HTTP error codes (de facto standard from the beginning)
• Web development documentation unification in 2017.

On your local machine, set up and test a local build. At least make certs and make web should succeed. If you decide to install Jekyll, make web-local should also succeed.

You should not push changes that do not compile locally -- currently, the build is broken (you're getting notification emails with every still failing push). This in practice means the web deploy will not run and I cannot see my changes online.

Look up what's wrong with X509_V_ERR_CA_MD_TOO_WEAK.
Generated certs produce the right error with OpenSSL 1.1.1, but with OpenSSL 1.1.1.c FIPS, the validation succeeds.

Try higher auth_level, level 2 is currently used when verifying.
See: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level.html

There is 3 of them:
X509_V_OK
X509_V_ERR_UNSPECIFIED
X509_V_ERR_PROXY_SUBJECT_INVALID

I.e. create the corresponding YAML files. For tags, [ openssl ] is sufficient now (we'll do the sectioning together).

Currently, some error cases use --infile endpoint.crt and others < endpoint.crt. Unify this for the former one.

Check which version of OpenSSL runs on Travis CI. Consider using the current master, i.e. building our own.

When a certificate chain fails to validate with the correct error message, the make fails.

However, if we try to build second time, then the chain had already been generated, no tests are run, and Make finishes correctly (even though it shouldn't).

What would be the correct way to solve this?

And link resulting ZIP files in the error list.

Add the dedicated authors file.

• Consider a left-docked panel asking for feedback.
• Possibly a pop-up after highlighting text.
• Primary is a link to GitHub issues, secondary is an email contact.

Currently, OpenSSL verification commands only had a single line. However, some GnuTLS commands (e.g. X509_­V_­ERR_­CRL_­HAS_­EXPIRED) have multiple lines. Are all these necessary? I do not think so. On the other hand, the possibility of multiple lines complicates displaying them.

• Saved in web/_data/error.yml.
• Displayed on the home page between the title and the error list.
• Listing the relevant names (e.g. official extension names) and linking the relevant RFCs.

Think it through and have consistent and accessible naming and error data.

• Error code (in various libraries?)
• Error documentation (in OpenSSL, in other libraries?)
• Script to generate the certificate (in various libraries?)
• Script to validate the certificate and get the error (in various libraries?)
• Templates for certificate generation
• Build folder (to generate final ZIP)

Further considerations:

• Global settings (verbosity level, folder with templates, folder for outputs, ...)
• We want script code to be exported to web

Look up what they are and where they should belong.
These are:
X509_V_ERR_AKID_SKID_MISMATCH
X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH
X509_V_ERR_NO_ISSUER_PUBLIC_KEY
X509_V_ERR_SIGNATURE_ALGORITHM_MISMATCH
X509_V_ERR_UNNESTED_RESOURCE
X509_V_ERR_OCSP_VERIFY_NEEDED

Comments can be added (starting with #) to separate sections.

• add colors for replicated / unreplicated errors
• add all errors from other (than OpenSSL) libraries
• separate errors mapped by hand / programmatically

Be transparent to which version of the documentation are we relating.

• For now: Just indicate if it's master or a specific version.
• Possible extensions: Selection box for different versions (required a recherche into how much does the documentation change).

Update generation of the web version in the footer using metadata instead of a custom bash script (the way faktaoklimatu.cz does).
Depends on #34.

What changes are to be done in OpenSSL 3.0? Are any of them relevant to us?

Install libraries, run a CLI where available, otherwise write validation code.

• GnuTLS
• NSS
• GnuPG
• mBedTLS
• Microsoft CryptoAPI
• Botan
• WolfSSL
• OpenJDK

E.g.:

• Don't use intermediate CSRs if not necessary,
• Generate a self-signed certificate in a single step.
• Cut out the unnecessary template items (and keep a unified style of names).
  Some simplifications have been done for the new structure.

Services are deprecated.

Including:

• library choice reasoning
• related research (including ours)
• merged pull requests based on this project

May or may not be useful -- this gives more emphasis on the situation in OpenSSL.

Such as security.txt, humans.txt and robots.txt.

For each case and library used, have the expected output in a file.

• It saves the trouble of running to see what the error says.
• It enables consistency self-tests -- generate everything and see if it still produces the same results.

Have descriptions/stories of the main use cases:

• Who are we building the website for?
• What will the people want to do there?

These will help us adjust the web to help accomplish these use cases.

First ideas:

1. Developer looking up for the error trying to understand and solve it.
2. Developer of a new library trying to adhere to the proposed error system.

Write a short contributing guide.
See for example https://github.com/kmindi/special-files-in-repository-root

Ask Petr Sekan or Matus Nemec to help.

Create example certificates for some error codes.