hcrudolph / ciphersuite.info Goto Github PK

Because the site is down, I did a git clone to spin up my own and it is also serving up a 500 error.

Django throws a warning that an unordered list may lead to inconsistent pagination ... which is exactly what happens:

That however, seems strange since the Rfc model does define a default ordering right here.

Hey guys,

hash functions are differently used in TLS.
For example TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256 uses SHA256 for the pseudo random function and the HMAC.

Opposite to that, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 uses the GCM as a HMAC substitute and SHA384 for the PRF. CCM ciphers have a similar behaviour.

It would be nice to have to see on your page, for what the algorithm is used. E.g.:
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Hash:
Secure Hash Algorithm 384 (SHA384) [used as pseudo random function]"

PSA: I'm quite not sure, if the hash function is used in the handshake as well. I believe in TLS1.3 it is standardized for all suites. But it should be easy to find out.

Cheers,
Matthias

Should be searchable for different CS syntax (IANA, OpenSSL, GnuTLS)
See https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table

Hey guys,

if you just want to find all super-duper-cool GCM suites, you'll first find a bunch of CBC suites which have the disclaimer "plz use GCM instead of this padding oracle mess".

The first GCM suite is on the 5th place, the second one on 11th.

Maybe the CBC disclaimer shouldn't be searchable or so? A filtering drop down per algorithm could be useful as well.

Thanks,
Matthias

Show defined and obsoleted cipher suits on RFC detail site.

Cipher suites that are currently only included in RFC drafts should be imported from the IANA TLS parameter list as well. The Rfc object should be clearly marked as having the status DRAFT in the model and link to the recent version on ietf.org, e.g.: https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17

Using Django's translation feature, translate all explanatory strings, i.e.:

• menu items
• vulnerability descriptions
• about page
• ...

Further customize the site's visuals so that it does not look like stock Bootstrap.

Add a mechanism for counting the most popular Cipher Suites, Algorithms, etc.

https://ciphersuite.info/ is showing DNS resolution issues. is the domain expired?

Hey guys,

https://ciphersuite.info/static/openapi.json shows two dead links.
Mentioned are:

• "https://git.hcrudolph.com/hcrudolph/ciphersuite.info/blob/master/LICENSE"
• "https://git.hcrudolph.com/hcrudolph/ciphersuite.info"

Thanks for your work!
Matthias

Hello. It seems to me a well laudable intention within the project which is to achieve a reliable ranking of cipher suites mathematical security strengths. Nonetheless, the obvious cannot be missed, in that ordering them accordingly is giving quite trouble to developers.

Illustration by comparison with two tool suites that conform with IETF's standardization publications. Both of them by default present cipher suites in descending order of supposed security strength, thus from strongest towards weakest.

GnuTLS v. 3.8.0

$ gnutls-cli -l --priority PFS | grep TLS1.3$
TLS_AES_256_GCM_SHA384                      0x13, 0x02	TLS1.3
TLS_CHACHA20_POLY1305_SHA256                0x13, 0x03	TLS1.3
TLS_AES_128_GCM_SHA256                      0x13, 0x01	TLS1.3
TLS_AES_128_CCM_SHA256                      0x13, 0x04	TLS1.3

OpenSSL v. 3.1

$ openssl ciphers -V -s -tls1_3
0x13,0x02 - TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x13,0x01 - TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128)            Mac=AEAD
0x13,0x04 - TLS_AES_128_CCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESCCM(128)            Mac=AEAD

When it comes to this tool, a non-standardised ordering can be observed.

Note: this tool suffers an issue (!112) that is out of scope in the context of the present report; selections of Ordering options Ascending and Descending trigger opposite operations. Then as long as the issue is alive, select the Ascending option in order to obtain a presentation ordered by descending.

For Security select All, for TLS version select TLS v. 1.3. Resulting output:

Secure TLS_AES_128_CCM_8_SHA256
Secure TLS_AES_128_CCM_SHA256
Recommended TLS_AES_128_GCM_SHA256
Recommended TLS_AES_256_GCM_SHA384
Recommended TLS_CHACHA20_POLY1305_SHA256
Insecure TLS_SHA256_SHA256
Insecure TLS_SHA384_SHA384
Insecure TLS_SM4_CCM_SM3
Insecure TLS_SM4_GCM_SM3

News in the navbar routes to RFC, not Blog page.
Quickfix is in place

https://ciphersuite.info/ returned server error.

Hello. The selections of Ordering options Ascending and Descending trigger opposite operations. Then for example, Ascending option would have to be selected in order to obtain a presentation ordered by descending, therefore from strongest to weakest in respect to theoretical security strength.

Illustration with that filters combination applied: for Security select All, for TLS version select TLS v. 1.3. Resulting output:

Secure TLS_AES_128_CCM_8_SHA256
Secure TLS_AES_128_CCM_SHA256
Recommended TLS_AES_128_GCM_SHA256
Recommended TLS_AES_256_GCM_SHA384
Recommended TLS_CHACHA20_POLY1305_SHA256
Insecure TLS_SHA256_SHA256
Insecure TLS_SHA384_SHA384
Insecure TLS_SM4_CCM_SM3
Insecure TLS_SM4_GCM_SM3

Just started using your excellent API and noticed the above omission at https://ciphersuite.info/api/cs/TLS_CHACHA20_POLY1305_SHA256. I believe the openssl_name value ought to be the same as the IANA name key. The json given by the API is as follows:-

{

    "TLS_CHACHA20_POLY1305_SHA256": {
        "gnutls_name": "",
        "openssl_name": "",
        "hex_byte_1": "0x13",
        "hex_byte_2": "0x03",
        "protocol_version": "TLS",
        "kex_algorithm": "-",
        "auth_algorithm": "-",
        "enc_algorithm": "CHACHA20 POLY1305",
        "hash_algorithm": "SHA256",
        "security": "recommended",
        "tls_version": [
            "TLS1.3"
        ]
    }

}

openssl ciphers|grep TLS_CHACHA20_POLY1305_SHA256 on my machine highlights this name (openssl 1.1.1f).

I also note the 2nd hex byte seems to be incorrectly recorded here as 0xC3 - an OCR scan error?

It would be nice to add Fips-140-3 compliance information for cipher suites.

On the "Cipher Suite" site the footer is cut off because the list is too long.

Add the information if cipher is an AEAD cipher.

In the view index_cs, retain the chosen filter argument as a URL parameter after sorting the list in order to allow filtering and searching at the same time.

Similar to the "Sort by"-button, there should be a "Filter by"-button allowing users to extract, e.g:

• only SECURE/WEAK/INSECURE cipher suites
• certain algorithms
• ...

Example:
Search for "aes" -> click on "RFC" tab -> click on RFC

Link format: "/cs/AES Galois Counter Mode (GCM) Cipher Suites for TLS"

Link contains spaces and can't be opened.

I saw that the below 2 ciphers are ranked as secure on their respective pages. We have a vulnerability scanning tool which flagged them as being vulnerable to the below mentioned DoS vulnerability.

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

https://ciphersuite.info/search/?q=TLS_DHE_RSA_WITH_AES_256_GCM_SHA

CVE-2002-20001
CVE-2022-40735

https://github.com/Balasys/dheater

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2002-20001

https://www.researchgate.net/profile/Anton-Stiglic-2/publication/2401745_Security_Issues_in_the_Diffie-Hellman_Key_Agreement_Protocol

The Diffie-Hellman Key Agreement Protocol allows remote attackers (from the client side) to send arbitrary numbers that are actually not public keys, and trigger expensive server-side DHE modular-exponentiation calculations, aka a D(HE)ater attack. The client needs very little CPU resources and network bandwidth. The attack may be more disruptive incases where a client can require a server to select its largest supported key size. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE.

Since there is now a first beta version of the next major Bootstrap release, we should consider making the switch to v4 soon.

Get some initial content in here.

I read in the ReadMe that the Cipher Suites are scraped from the IANA TLS Cipher Suite Registry, though I'm not sure if the GnuTLS availability data could be parsed from the Supported ciphersuites appendix from the manual.

This may help automate the listing of the availability for GnuTLS specifically.

Backend editor for adding/editing text like the about page.

Search functionality no longer allows searching the RFC title.

NULL ciphers are shown as using HMAC, even if there is no integrity protection.

Example: https://ciphersuite.info/cs/TLS_NULL_WITH_NULL_NULL/

The CCM (8) mode was shown as the hash algorithm which is wrong.
Quick & Dirty fix was to delete all CCM ciphers from the database, editing the cipher suite parsing code, then to reimport all ciphers.

Following edit in the signals.py was made:
` # split enc again if we only got a number for hsh
# specifically needed for 'CCM 8' hash algorithm
#if re.match(r'\d+', hsh.strip()):
# (enc,_,ccm) = enc.rpartition(" ")
# hsh = ccm + " " + hsh

    if re.match(r'\d+', hsh.strip()):
         (enc,_,ccm) = enc.rpartition(" ")
         enc = enc + " " + ccm + " 8"
         hsh = "SHA256"

    if re.match(r'CCM\Z', hsh.strip()):
         (enc,_,ccm) = enc.rpartition(" ")
         enc = enc + " " + ccm + " CCM"
         hsh = "SHA256"`

I'm currently looking at the tshark -V capture of a connection between two mail servers that cannot negotiate a common cipher, because on of those servers supports only weak ciphers.

The list of supported ciphers from the remote server looks like this in the tshark output:

[...]
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 122
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 118
            Version: TLS 1.2 (0x0303)
            Random: 62a34968a18a0a05ca020e7d151c5a694a3d6afb1f3f3cf1...
                GMT Unix Time: Jun 10, 2022 15:38:48.000000000 CEST
                Random Bytes: a18a0a05ca020e7d151c5a694a3d6afb1f3f3cf156955a03...
            Session ID Length: 0
            Cipher Suites Length: 22
            Cipher Suites (11 suites)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Compression Methods Length: 1
[...]

I can now look up these ciphers one-by-one on ciphersuite.info, e.g. https://ciphersuite.info/search/?q=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

But I feel it would be very useful if I could search for multiple ciphers at once. I tried to turn them into a space separated list in vim, but that doesn't work in the search: https://ciphersuite.info/search/?q=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA+TLS_ECDHE_RSA_WITH_AES_128_

This is to be expected because the search is probably ANDing my keywords instead of ORing them, but a dedicated search form that can OR the search terms to easily look up multiple ciphers would probably be useful. It might even parse ciphers names from the input and ignore everything else, so that users could copy-paste the tshark output verbatim into the search field:

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Adapt search so placeholder can be - or _

It's my understanding that you rate all cipher suites without PFS as "weak". If that's the case, both "secure" and "recommended" all support PFS.

The FAQ currently only states this for recommended, implying that cipher suites under "secure" don't guarantee it.

The IANA TLS cipher suite registry is available in csv format at the following location:

https://www.iana.org/assignments/tls-parameters/tls-parameters-4.csv

The scrapeiana admin command should be reworked to parse this file rather than scrape the whole HTML page.

After each deploy the sponsor logo is deleted from the filesystem. The uploaded files should be excluded from deletion during redeployment.

The responses seem to be wrapped in additional elements. Because of this, automatic client generation with e.g. NSwag does not result in a working client.

For example this GET request:

https://ciphersuite.info/api/cs/TLS_AES_256_GCM_SHA384

returns response:

{
    "TLS_AES_256_GCM_SHA384": {
        "gnutls_name": "",
        "openssl_name": "TLS_AES_256_GCM_SHA384",
        "hex_byte_1": "0x13",
        "hex_byte_2": "0x02",
        "protocol_version": "TLS",
        "kex_algorithm": "-",
        "auth_algorithm": "-",
        "enc_algorithm": "AES 256 GCM",
        "hash_algorithm": "SHA384",
        "security": "recommended",
        "tls_version": [
            "TLS1.3"
        ]
    }
}

OpenAPI response definition:

"Ciphersuite": {
    "type": "object",
    "properties": {
    "gnutls_name": {
        "type": "string"
    },
    "openssl_name": {
        "type": "string"
    },
    "tls_version": {
        "type": "string",
        "enum": [
        "TLS1.0",
        "TLS1.1",
        "TLS1.2",
        "TLS1.3"
        ]
    },
    "hex_byte_1": {
        "type": "string"
    },
    "hex_byte_2": {
        "type": "string"
    },
    "protocol_version": {
        "type": "string"
    },
    "kex_algorithm": {
        "type": "string"
    },
    "auth_algorithm": {
        "type": "string"
    },
    "enc_algorithm": {
        "type": "string"
    },
    "hash_algorithm": {
        "type": "string"
    }
    }
}

Expected response according to OpenAPI definition:

{
    "gnutls_name": "",
    "openssl_name": "TLS_AES_256_GCM_SHA384",
    "hex_byte_1": "0x13",
    "hex_byte_2": "0x02",
    "protocol_version": "TLS",
    "kex_algorithm": "-",
    "auth_algorithm": "-",
    "enc_algorithm": "AES 256 GCM",
    "hash_algorithm": "SHA384",
    "security": "recommended",
    "tls_version": [
        "TLS1.3"
    ]
}

The name of export-grade cipher suites currently is not parsed correctly, resulting in faulty entries in their respective *_algorithm attributes.

Return button on Cipher Suite detail site so you can go back to your search results.
Return over the browser isn't the nicest way.

Having a last_update field in server's response, or in a specific endpoint will help building a cache on client side.
The field will be update each time a cipher suite is declared as weak or insecure, in case of new cipher published.
Is there a chance to get this kind of feature ?

I think we need a robots.txt file to get more control over web crawlers.

1000 characters turns out to be far to little space (cf. https://github.com/hcrudolph/ciphersuite.info/blob/master/directory/models.py#L193).

Let's design a logo for usage in the website's navbar.

RFC 9189 published three new ciphers with completely different names. This results in a broken mapping for OpenSSL and GnuTLS (at the moment only in staging)

RFC 9150 messes with naming scheme too

I'm not sure if this is the right place to file this.

I received the following error when trying to join through Element to the Matrix room:

Invalid signature for server matrix.org with key ed25519:a_RXGa: Unable to verify signature for matrix.org: <class 'nacl.exceptions.BadSignatureError'> Signature was forged or corrupt

This may or may not end up being a server config error:
matrix-org/synapse#3387

Currently the api response returned either "recommended|secure|weak|insecure". Please add more description to the api response why it was tagged as "weak" just like what you did in your website.

Example:
TLS_RSA_WITH_AES_256_CBC_SHA - Weak (Kex:PFS not supported, Enc:CBC, Hash:SHA1 )