Network Security Services package and Pretty-print utility
The Network Security Services ( NSS ) package is a set of libraries used in the cross-platform development of secure client and server applications.
The NSS package, like OpenSSL, provides the ability to use command line utilities for implementing various PKI functions (key generation, issuing x509v3 certificates, working with electronic signatures, TLS support, etc.). One of these utilities, namely Pretty-print (PP), allows you to view in a convenient way the contents of both the x509 v3 certificate and the electronic signature (pkcs # 7), etc. At what certificate can be both in DER, and PEM-coding:
Moreover, the presence of the –u parameter (UTF-8 encoding) allows you to view the certificate in Russian encoding. But looking carefully at the screenshots of the graphical interface to the command line utilities of the NSS package, you notice that some of the certificate data just disappeared:
Began the search for missing information. The “pretty print” utility (namely, pretty-print is translated) for viewing the root certificate of the Head CA of the Ministry of Communications and Mass Media was launched on the command line:
The result confirmed the loss of data. Moreover, two non-displayable symbols appeared on the screen (a black black diamond with a question mark? Inside). The analysis showed that these non-displayable characters have codes 0xD0 and 0xBE, respectively:
The Russian letter “o” with a hexadecimal representation in UTF-8 encoding as 0xD00xBE has disappeared. And codes 0xD0 and 0xBE are our non-displayable characters. And what characters appeared between these bytes? And this is the "cute" print - the characters align the printed text.
What happened? The input of the “nice” print (file /nss/cmd/lib/secutil.c, the secu_PrintRawStringQuotesOptional function) comes in the form of SECITEM, i.e. addresses byte array and its length:
And if provided (SECU_GetWrapEnabled () == True) is a nice print (lack of the –w parameter of the PP utility) and the number of bytes in the line exceeds 76 (column> 76), then a new line (SECU_Newline) and the necessary indents (SECU_Indent) are inserted after the next character ). At the same time, none of the developers thought about the fact that if UTF-8 (utf8DisplayEnabled) is used, then beauty can only be induced after the next character, not byte, because the concept of a byte and a character in UTF-8 encoding may not coincide . If we talk about Russian letters, then each of them is encoded in two bytes. This is the gap that occurred with our Russian letter “o” (0xD00xBE).
What is the way out? It's very simple enough in the secu_PrintRawStringQuotesOptional function to replace the string:
on the line of the following form:
If you now rebuild the PP utility and install it into the system, then the “nice” seal will justify its name for the “great, powerful, truthful and free Russian language!” (I.S. Turgenev):
If we talk about the beauty of printing, we could add a hyphen not only by the number of characters per line, but more correct, for example, by space, comma, colon, and other characters. I'm not talking about semantic analysis during the transfer. But this is an area of artificial intelligence.
And finally, this is the second detected inaccuracy in the NSS utilities. The first was found in the oidcalc utility.
The NSS package, like OpenSSL, provides the ability to use command line utilities for implementing various PKI functions (key generation, issuing x509v3 certificates, working with electronic signatures, TLS support, etc.). One of these utilities, namely Pretty-print (PP), allows you to view in a convenient way the contents of both the x509 v3 certificate and the electronic signature (pkcs # 7), etc. At what certificate can be both in DER, and PEM-coding:
bash-4.3$ pp -h Usage: pp [-t type] [-a] [-i input] [-o output] [-w] [-u] Pretty prints a file containing ASN.1 data in DER or ascii format. -t type Specify input and display type: public-key (pk), certificate (c), certificate-request (cr), certificate-identity (ci), pkcs7 (p7), crl or name (n). (Use either the long type name or the shortcut.) -a Input is in ascii encoded form (RFC1113) -i input Define an input file to use (default is stdin) -o output Define an output file to use (default is stdout) -w Don't wrap long output lines -u Use UTF-8 (default is to show non-ascii as .) bash-4.3$
Moreover, the presence of the –u parameter (UTF-8 encoding) allows you to view the certificate in Russian encoding. But looking carefully at the screenshots of the graphical interface to the command line utilities of the NSS package, you notice that some of the certificate data just disappeared:
Began the search for missing information. The “pretty print” utility (namely, pretty-print is translated) for viewing the root certificate of the Head CA of the Ministry of Communications and Mass Media was launched on the command line:
$pp – certificate –u –i _.cer … Subject: "CN= ,INN=007710474375,OGRN=1047702026701,O= ,STREET="125375 . , . , . 7",L=,ST=77 . ,C=RU,E=dit@minsvya z.ru" …. $
The result confirmed the loss of data. Moreover, two non-displayable symbols appeared on the screen (a black black diamond with a question mark? Inside). The analysis showed that these non-displayable characters have codes 0xD0 and 0xBE, respectively:
The Russian letter “o” with a hexadecimal representation in UTF-8 encoding as 0xD00xBE has disappeared. And codes 0xD0 and 0xBE are our non-displayable characters. And what characters appeared between these bytes? And this is the "cute" print - the characters align the printed text.
What happened? The input of the “nice” print (file /nss/cmd/lib/secutil.c, the secu_PrintRawStringQuotesOptional function) comes in the form of SECITEM, i.e. addresses byte array and its length:
for (i = 0; i < si->len; i++) { unsigned char val = si->data[i]; unsigned char c; if (SECU_GetWrapEnabled() && column > 76) { SECU_Newline(out); SECU_Indent(out, level); column = level * INDENT_MULT; } if (utf8DisplayEnabled) { if (val < 32) c = '.'; else c = val; } else { c = printable[val]; } fprintf(out, "%c", c); column++; }
And if provided (SECU_GetWrapEnabled () == True) is a nice print (lack of the –w parameter of the PP utility) and the number of bytes in the line exceeds 76 (column> 76), then a new line (SECU_Newline) and the necessary indents (SECU_Indent) are inserted after the next character ). At the same time, none of the developers thought about the fact that if UTF-8 (utf8DisplayEnabled) is used, then beauty can only be induced after the next character, not byte, because the concept of a byte and a character in UTF-8 encoding may not coincide . If we talk about Russian letters, then each of them is encoded in two bytes. This is the gap that occurred with our Russian letter “o” (0xD00xBE).
What is the way out? It's very simple enough in the secu_PrintRawStringQuotesOptional function to replace the string:
if (SECU_GetWrapEnabled() && column > 76) {
on the line of the following form:
if (SECU_GetWrapEnabled() && column > 76 && (val <= 0x7F || val == 0xD0 || val == 0xD1)) {
If you now rebuild the PP utility and install it into the system, then the “nice” seal will justify its name for the “great, powerful, truthful and free Russian language!” (I.S. Turgenev):
If we talk about the beauty of printing, we could add a hyphen not only by the number of characters per line, but more correct, for example, by space, comma, colon, and other characters. I'm not talking about semantic analysis during the transfer. But this is an area of artificial intelligence.
And finally, this is the second detected inaccuracy in the NSS utilities. The first was found in the oidcalc utility.
All Articles