[jira] [Created] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
Lonzak created TIKA-4194:
Summary: tika fails to detect certain pkcs12 keystores types p12
pfx
Key: TIKA-4194
URL: https://issues.apache.org/jira/browse/TIKA-4194
Project: Tika
Issue Type: Bug
Components: detector
Affects Versions: 2.9.1
Reporter: Lonzak
We use tika to detect the type of a file which is uploaded. In most cases this
works quite well. However recently some files were rejected because tika
reports an invalid file type. We'll get
{code:java}
APPLICATION/OCTET-STREAM{code}
instead of
{code:java}
APPLICATION/X-X509-KEY{code}
I did an analysis and found that tika doesn't recognize certain types of pkcs12
keystores. The test keystores can be found
[here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
I created a list to show which ones are effected. Out of 157 keystores 132 are
correctly detected and 25 are not.
||#||correct?||type||filename||
|1|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|2|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|3|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|4|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|5|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
|6|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|7|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|8|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|9|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|10|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|11|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
|12|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|13|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|14|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|15|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|16|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|17|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|18|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|19|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(hmacWithSHA256)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|20|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(8),prf(default)),rc2-cbc(keyBits(120=64bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|21|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKD
[jira] [Commented] (TIKA-3841) 使用tika解析部分word文档出现异常，tika_exception
[
https://issues.apache.org/jira/browse/TIKA-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816035#comment-17816035
]
Lonzak commented on TIKA-3841:
--
My chinese is a bit rusty so can someone change the title to: Exception when
using tika to parse some Word documents, tika_exception ? Thanks
> 使用tika解析部分word文档出现异常，tika_exception
> ---
>
> Key: TIKA-3841
> URL: https://issues.apache.org/jira/browse/TIKA-3841
> Project: Tika
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.24, 2.4.1, 1.28.4
> Environment: h3. Java Version
> java version "1.8.0_291"
> h3. OS Version
> Linux localhost.localdomain 3.10.0-957.el7.x86_64
> [#1|https://github.com/elastic/elasticsearch/issues/1] SMP Thu Nov 8 23:39:32
> UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: lxz
>Priority: Blocker
>
> {
> "error": {
> "root_cause": [
> { "type": "parse_exception", "reason": "Error parsing
> document in field [content]" }
> ],
> "type": "parse_exception",
> "reason": "Error parsing document in field [content]",
> "caused_by": {
> "type": "tika_exception",
> "reason": "Unexpected RuntimeException from
> org.apache.tika.parser.microsoft.OfficeParser@3b5e180a",
> "caused_by":
> { "type": "array_index_out_of_bounds_exception",
> "reason": "351" }
> }
> },
> "status": 400
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (TIKA-3841) 使用tika解析部分word文档出现异常，tika_exception
[
https://issues.apache.org/jira/browse/TIKA-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816035#comment-17816035
]
Lonzak edited comment on TIKA-3841 at 2/9/24 12:20 PM:
---
My Chinese is a bit rusty so can someone change the title to: Exception when
using tika to parse some Word documents, tika_exception ? Thanks
was (Author: tom_1st):
My chinese is a bit rusty so can someone change the title to: Exception when
using tika to parse some Word documents, tika_exception ? Thanks
> 使用tika解析部分word文档出现异常，tika_exception
> ---
>
> Key: TIKA-3841
> URL: https://issues.apache.org/jira/browse/TIKA-3841
> Project: Tika
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.24, 2.4.1, 1.28.4
> Environment: h3. Java Version
> java version "1.8.0_291"
> h3. OS Version
> Linux localhost.localdomain 3.10.0-957.el7.x86_64
> [#1|https://github.com/elastic/elasticsearch/issues/1] SMP Thu Nov 8 23:39:32
> UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: lxz
>Priority: Blocker
>
> {
> "error": {
> "root_cause": [
> { "type": "parse_exception", "reason": "Error parsing
> document in field [content]" }
> ],
> "type": "parse_exception",
> "reason": "Error parsing document in field [content]",
> "caused_by": {
> "type": "tika_exception",
> "reason": "Unexpected RuntimeException from
> org.apache.tika.parser.microsoft.OfficeParser@3b5e180a",
> "caused_by":
> { "type": "array_index_out_of_bounds_exception",
> "reason": "351" }
> }
> },
> "status": 400
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816122#comment-17816122
]
Lonzak commented on TIKA-4194:
--
I did investigate a bit further - (however my knowledge in this area is quite
limited):
Tika is indeed looking at the bytes - a working keystore has the following
"Magic" matcher:
[40/application/x-x509-key; format=der string 0 0x3082020100
0xFC]
If I open that file in a hex editor I can see:
{code:java}
0x 30 82 10 29 02 01 03 30 82 (Bits from a working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class)
{code}
This seems to match except for the FF and last 00 values. (Maybe these bytes
are ignored?)
If I open a non working one I get:
{code:java}
0x 30 80 02 01 03 30 80 (Bits from a non working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class){code}
So the 2nd hex number is different thus it is not a match I would guess. But
the bits also seems to to be shifted?
{code:java}
0x 30 80 02 01 03 30 80 (Bits from a non working keystore)
0x 30 82 10 29 02 01 03 30 82 (Bits from a working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class){code}
So an approach could be to add the missing magic bytes to an existing/new Magic
class?
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=D
[jira] [Comment Edited] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816122#comment-17816122
]
Lonzak edited comment on TIKA-4194 at 2/9/24 4:15 PM:
--
I did investigate a bit further - (however my knowledge in this area is quite
limited):
Tika is indeed looking at the bytes - a working keystore has the following
"Magic" matcher:
[40/application/x-x509-key; format=der string 0 0x3082020100
0xFC]
If I open that file in a hex editor I can see:
{code:java}
0x 30 82 10 29 02 01 03 30 82 (Bits from a working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class)
{code}
This seems to match except for the FF and last 00 values. (Maybe these bytes
are ignored?)
If I open a non working one I get:
{code:java}
0x 30 80 02 01 03 30 80 (Bits from a non working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class){code}
So the 2nd hex number is different thus it is not a match I would guess. But
the bits also seems to to be shifted?
{code:java}
0x 30 80 02 01 03 30 80 (Bits from a non working keystore)
0x 30 82 10 29 02 01 03 30 82 (Bits from a working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class){code}
So an approach could be to add the missing magic bytes to an existing/new Magic
class?
So maybe a matcher:
{{magic=0x3080FF3080}}
would work?{{{}{}}}
was (Author: tom_1st):
I did investigate a bit further - (however my knowledge in this area is quite
limited):
Tika is indeed looking at the bytes - a working keystore has the following
"Magic" matcher:
[40/application/x-x509-key; format=der string 0 0x3082020100
0xFC]
If I open that file in a hex editor I can see:
{code:java}
0x 30 82 10 29 02 01 03 30 82 (Bits from a working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class)
{code}
This seems to match except for the FF and last 00 values. (Maybe these bytes
are ignored?)
If I open a non working one I get:
{code:java}
0x 30 80 02 01 03 30 80 (Bits from a non working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class){code}
So the 2nd hex number is different thus it is not a match I would guess. But
the bits also seems to to be shifted?
{code:java}
0x 30 80 02 01 03 30 80 (Bits from a non working keystore)
0x 30 82 10 29 02 01 03 30 82 (Bits from a working keystore)
0x 30 82 FF FF 02 01 00 (magic bytes from the Magic class){code}
So an approach could be to add the missing magic bytes to an existing/new Magic
class?
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048
[jira] [Commented] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816132#comment-17816132
]
Lonzak commented on TIKA-4194:
--
I read a bit more. The whole context is ASN.1 DER encoding.
"30 82" is followed by two further bytes that specify the length of the
SEQUENCE in an explicit number. This enables the coding of objects with a
length of up to 65535 (0x) bytes.
"30 80", on the other hand, signals the start of a SEQUENCE with an undefined
length. The final length of the SEQUENCE is not specified in advance. Instead,
the end of the SEQUENCE is marked by a special end-of-contents (EOC) marker
pair "00 00". This encoding method is typically used when the total length of
the SEQUENCE is not known at the time of encoding or when it is practical to
treat the data as a stream.
To cover both cases, one could define an additional rule or adjust the existing
rule to be more flexible. Directly adapting the current rule to include
{{0x3080}} could be challenging because the structure and logic behind the
length indication and subsequent content are different. Instead, we might need
to add a new rule specifically targeting keystores with {{{}0x3080{}}}. Note,
however, that detecting content with indefinite length is more challenging, as
one may not be able to straightforwardly check for a specific byte sequence
after {{{}0x3080{}}}.
{code:java}
[40/application/x-x509-key; format=der string 0 0x3080??]{code}
In this hypothetical rule, {{??}} stands for a placeholder, as the
specific handling for content with indefinite length needs to be adjusted,
possibly by implementing a logic that recognizes the end of the stream instead
of relying on fixed byte patterns.
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
[jira] [Comment Edited] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816132#comment-17816132
]
Lonzak edited comment on TIKA-4194 at 2/9/24 5:52 PM:
--
I read a bit [more|https://stackoverflow.com/a/31451808/2311528]. The whole
context is ASN.1 DER encoding. So it is not magic bytes but ASN.1 encoding...
"30 82" is followed by two further bytes that specify the length of the
SEQUENCE in an explicit number. This enables the coding of objects with a
length of up to 65535 (0x) bytes.
"30 80", on the other hand, signals the start of a SEQUENCE with an undefined
length. The final length of the SEQUENCE is not specified in advance. Instead,
the end of the SEQUENCE is marked by a special end-of-contents (EOC) marker
pair "00 00". This encoding method is typically used when the total length of
the SEQUENCE is not known at the time of encoding or when it is practical to
treat the data as a stream.
To cover both cases, one could define an additional rule or adjust the existing
rule to be more flexible. Directly adapting the current rule to include
{{0x3080}} could be challenging because the structure and logic behind the
length indication and subsequent content are different. Instead, we might need
to add a new rule specifically targeting keystores with {{{}0x3080{}}}. Note,
however, that detecting content with indefinite length is more challenging, as
one may not be able to straightforwardly check for a specific byte sequence
after {{{}0x3080{}}}.
{code:java}
[40/application/x-x509-key; format=der string 0 0x3080??]{code}
In this hypothetical rule, {{??}} stands for a placeholder, as the
specific handling for content with indefinite length needs to be adjusted,
possibly by implementing a logic that recognizes the end of the stream instead
of relying on fixed byte patterns.
was (Author: tom_1st):
I read a bit more. The whole context is ASN.1 DER encoding.
"30 82" is followed by two further bytes that specify the length of the
SEQUENCE in an explicit number. This enables the coding of objects with a
length of up to 65535 (0x) bytes.
"30 80", on the other hand, signals the start of a SEQUENCE with an undefined
length. The final length of the SEQUENCE is not specified in advance. Instead,
the end of the SEQUENCE is marked by a special end-of-contents (EOC) marker
pair "00 00". This encoding method is typically used when the total length of
the SEQUENCE is not known at the time of encoding or when it is practical to
treat the data as a stream.
To cover both cases, one could define an additional rule or adjust the existing
rule to be more flexible. Directly adapting the current rule to include
{{0x3080}} could be challenging because the structure and logic behind the
length indication and subsequent content are different. Instead, we might need
to add a new rule specifically targeting keystores with {{{}0x3080{}}}. Note,
however, that detecting content with indefinite length is more challenging, as
one may not be able to straightforwardly check for a specific byte sequence
after {{{}0x3080{}}}.
{code:java}
[40/application/x-x509-key; format=der string 0 0x3080??]{code}
In this hypothetical rule, {{??}} stands for a placeholder, as the
specific handling for content with indefinite length needs to be adjusted,
possibly by implementing a logic that recognizes the end of the stream instead
of relying on fixed byte patterns.
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyT
[jira] [Commented] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816608#comment-17816608
]
Lonzak commented on TIKA-4194:
--
Added a pull request: https://github.com/apache/tika/pull/1589
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |19|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PB
[jira] [Commented] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816607#comment-17816607
]
Lonzak commented on TIKA-4194:
--
Interestingly the "application/pkcs7-signature" type looks quite similar:
{code:java}
{code}
Just had to adapt the offset a bit and and did work:
{code:java}
{code}
However I didn't find a keystore with 0x3081 so the offset is unclear in that
case. My solution would look like this now and works for all the cases...
{code:java}
...
{code}
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |1
[jira] [Comment Edited] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816607#comment-17816607
]
Lonzak edited comment on TIKA-4194 at 2/12/24 1:47 PM:
---
Interestingly the "application/pkcs7-signature" type looks quite similar:
{code:java}
{code}
Just had to adapt the offset a bit and and did work:
{code:java}
{code}
However I didn't find a keystore with 0x3081 so the offset is unclear in that
case. My solution would look like this now and works for all the cases...
{code:java}
...
{code}
was (Author: tom_1st):
Interestingly the "application/pkcs7-signature" type looks quite similar:
{code:java}
{code}
Just had to adapt the offset a bit and and did work:
{code:java}
{code}
However I didn't find a keystore with 0x3081 so the offset is unclear in that
case. My solution would look like this now and works for all the cases...
{code:java}
...
{code}
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X
[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file
[
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816811#comment-17816811
]
Lonzak commented on TIKA-3784:
--
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
1.2.840.113549.1.7.6
1.2.840.113549.1.7.1
1.2.840.113549.1.12.1.6
0x7F432D60BCD2888476E6CB9CD2BC69F1
2000
0x...(shortened fro readability)
0x0E8E4C15DCB1D87F
1.3.14.3.2.26
0x6DFFA14B5A8A32A87DAD2CFCE1EAEBDAFB89C897
0x826699C21B9A4C9E3E608D3C8FBD2310
2000
{code}
The following things points to a pkcs12 format:
# Presence of PKCS#12-specific object identifiers (OIDs):
## PKCS#12 Bag Types: presence of OIDs such as 1.2.840.113549.1.12.10.1.x,
which indicate different types of key and certificate bags (KeyBags, CertBags,
etc.).
## PKCS#12 PbeIds: Encryption and hashing OIDs such as
1.2.840.113549.1.12.1.x, which indicate the use of specific encryption
mechanisms
# Use of encryption schemes:
## Recognize encryption schemes, especially those that are typical for
PKCS#12, such as pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd40BitRC2-CBC.
These schemes are crucial for the security of PKCS#12 files and a clear
indication of their presence.
# Structure of the file:
## Analyzing the file structure for multi-level nested SEQUENCE and
OCTET_STRING elements, which are typically used to store encrypted private keys
and certificates. The complexity of this structure is characteristic of PKCS#12
files.
# Specific attributes:
## PKCS#9 attributes such as friendlyName (OID 1.2.840.113549.1.9.20) and
localKeyID (OID 1.2.840.113549.1.9.21) are commonly used to provide metadata
for keys and certificates within the container.
# ... and more
However since we are already talking about Libraries - Standard Java Crypto and
BouncyCastle have all this already inside. They are parsing the structures,
analyze and use it. So using one of these two would be the easiest solution
imho. I have never written a Detector so please excuse my ignorance:
{code:java}
public class PKCS12Detector implements Detector {
private static final long serialVersionUID = -8414458255467101503L;
private static final MediaType PKCS12_MEDIA_TYPE =
MediaType.application("x-pkcs12");
@Override
public MediaType detect(InputStream input, Metadata metadata) {
try {
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(input, null);
return PKCS12_MEDIA_TYPE; // success
}
catch (Exception e) {
return MediaType.OCTET_STREAM; // something else
}
}
} {code}
A bouncy castle one would look quite similar...
> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found
> the following MIME magic which explains why I got these types back.
> {code:xml}
>
>
>
>
>
>
>
[jira] [Updated] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak updated TIKA-4194:
-
Description:
We use tika to detect the type of a file which is uploaded. In most cases this
works quite well. However recently some files were rejected because tika
reports an invalid file type. We'll get
{code:java}
APPLICATION/OCTET-STREAM{code}
instead of
{code:java}
APPLICATION/X-X509-KEY{code}
(As pointed out in TIKA-3784 the mimetype should really be
"application/x-pkcs12" but for us "application/x-x509-key" works for now)
I did an analysis and found that tika doesn't recognize certain types of pkcs12
keystores. The test keystores can be found
[here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
I created a list to show which ones are effected. Out of 157 keystores 132 are
correctly detected and 25 are not.
||#||correct?||type||filename||
|1|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|2|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|3|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|4|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|5|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
|6|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|7|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|8|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|9|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|10|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|11|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
|12|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|13|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|14|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|15|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|16|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|17|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|18|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|19|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(hmacWithSHA256)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|20|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(8),prf(default)),rc2-cbc(keyBits(120=64bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
|21|OK|APPLICATION/X-X509-KEY;
FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(defaul
[jira] [Comment Edited] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file
[
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816811#comment-17816811
]
Lonzak edited comment on TIKA-3784 at 2/12/24 11:15 PM:
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
1.2.840.113549.1.7.6
1.2.840.113549.1.7.1
1.2.840.113549.1.12.1.6
0x7F432D60BCD2888476E6CB9CD2BC69F1
2000
0x...(shortened fro readability)
0x0E8E4C15DCB1D87F
1.3.14.3.2.26
0x6DFFA14B5A8A32A87DAD2CFCE1EAEBDAFB89C897
0x826699C21B9A4C9E3E608D3C8FBD2310
2000
{code}
The oid is 3x in there - among others. The following things point to a pkcs12
format:
# Presence of PKCS#12-specific object identifiers (OIDs):
## PKCS#12 Bag Types: presence of OIDs such as 1.2.840.113549.1.12.10.1.x,
which indicate different types of key and certificate bags (KeyBags, CertBags,
etc.).
## PKCS#12 PbeIds: Encryption and hashing OIDs such as
1.2.840.113549.1.12.1.x, which indicate the use of specific encryption
mechanisms
# Use of encryption schemes:
## Recognize encryption schemes, especially those that are typical for
PKCS#12, such as pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd40BitRC2-CBC.
These schemes are crucial for the security of PKCS#12 files and a clear
indication of their presence.
# Structure of the file:
## Analyzing the file structure for multi-level nested SEQUENCE and
OCTET_STRING elements, which are typically used to store encrypted private keys
and certificates. The complexity of this structure is characteristic of PKCS#12
files.
# Specific attributes:
## PKCS#9 attributes such as friendlyName (OID 1.2.840.113549.1.9.20) and
localKeyID (OID 1.2.840.113549.1.9.21) are commonly used to provide metadata
for keys and certificates within the container.
# ... and more
However since we are already talking about Libraries - Standard Java Crypto and
BouncyCastle have all this already inside. They are parsing the structures,
analyze and use it. So using one of these two would be the easiest solution
imho. I have never written a Detector so please excuse my ignorance:
{code:java}
public class PKCS12Detector implements Detector {
private static final long serialVersionUID = -8414458255467101503L;
private static final MediaType PKCS12_MEDIA_TYPE =
MediaType.application("x-pkcs12");
@Override
public MediaType detect(InputStream input, Metadata metadata) {
try {
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(input, null);
return PKCS12_MEDIA_TYPE; // success
}
catch (Exception e) {
return MediaType.OCTET_STREAM; // something else
}
}
} {code}
A bouncy castle one would look quite similar...
was (Author: tom_1st):
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
[jira] [Comment Edited] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file
[
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816811#comment-17816811
]
Lonzak edited comment on TIKA-3784 at 2/12/24 11:16 PM:
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
1.2.840.113549.1.7.6
1.2.840.113549.1.7.1
1.2.840.113549.1.12.1.6
0x7F432D60BCD2888476E6CB9CD2BC69F1
2000
0x...(shortened fro readability)
0x0E8E4C15DCB1D87F
1.3.14.3.2.26
0x6DFFA14B5A8A32A87DAD2CFCE1EAEBDAFB89C897
0x826699C21B9A4C9E3E608D3C8FBD2310
2000
{code}
The oid is 3x in there - among others. The following things point to a pkcs12
format:
# Presence of PKCS#12-specific object identifiers (OIDs):
## PKCS#12 Bag Types: presence of OIDs such as 1.2.840.113549.1.12.10.1.x,
which indicate different types of key and certificate bags (KeyBags, CertBags,
etc.).
## PKCS#12 PbeIds: Encryption and hashing OIDs such as
1.2.840.113549.1.12.1.x, which indicate the use of specific encryption
mechanisms
# Use of encryption schemes:
## Recognize encryption schemes, especially those that are typical for
PKCS#12, such as pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd40BitRC2-CBC.
These schemes are crucial for the security of PKCS#12 files and a clear
indication of their presence.
# Structure of the file:
## Analyzing the file structure for multi-level nested SEQUENCE and
OCTET_STRING elements, which are typically used to store encrypted private keys
and certificates. The complexity of this structure is characteristic of PKCS#12
files.
# Specific attributes:
## PKCS#9 attributes such as friendlyName (OID 1.2.840.113549.1.9.20) and
localKeyID (OID 1.2.840.113549.1.9.21) are commonly used to provide metadata
for keys and certificates within the container.
# ... and more
However since we are already talking about Libraries - Standard Java Crypto and
BouncyCastle have all this already inside. They are parsing the structures,
analyze and use it. So using one of these two would be the easiest solution
imho. I have never written a Detector so please excuse my ignorance:
{code:java}
public class PKCS12Detector implements Detector {
private static final long serialVersionUID = -8414458255467101503L;
private static final MediaType PKCS12_MEDIA_TYPE =
MediaType.application("x-pkcs12");
@Override
public MediaType detect(InputStream input, Metadata metadata) {
try {
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(input, null);
return PKCS12_MEDIA_TYPE; // success
}
catch (Exception e) {
return MediaType.OCTET_STREAM; // something else
}
}
} {code}
A bouncy castle one would look quite similar. And also the Keystore loading
takes quite some time..
was (Author: tom_1st):
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
[jira] [Comment Edited] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file
[
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816811#comment-17816811
]
Lonzak edited comment on TIKA-3784 at 2/13/24 8:14 AM:
---
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
1.2.840.113549.1.7.6
1.2.840.113549.1.7.1
1.2.840.113549.1.12.1.6
0x7F432D60BCD2888476E6CB9CD2BC69F1
2000
0x...(shortened fro readability)
0x0E8E4C15DCB1D87F
1.3.14.3.2.26
0x6DFFA14B5A8A32A87DAD2CFCE1EAEBDAFB89C897
0x826699C21B9A4C9E3E608D3C8FBD2310
2000
{code}
The oid is 3x in there - among others. The following things point to a pkcs12
format:
# Presence of PKCS#12-specific object identifiers (OIDs):
## PKCS#12 Bag Types: presence of OIDs such as 1.2.840.113549.1.12.10.1.x,
which indicate different types of key and certificate bags (KeyBags, CertBags,
etc.).
## PKCS#12 PbeIds: Encryption and hashing OIDs such as
1.2.840.113549.1.12.1.x, which indicate the use of specific encryption
mechanisms
# Use of encryption schemes:
## Recognize encryption schemes, especially those that are typical for
PKCS#12, such as pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd40BitRC2-CBC.
These schemes are crucial for the security of PKCS#12 files and a clear
indication of their presence.
# Structure of the file:
## Analyzing the file structure for multi-level nested SEQUENCE and
OCTET_STRING elements, which are typically used to store encrypted private keys
and certificates. The complexity of this structure is characteristic of PKCS#12
files.
# Specific attributes:
## PKCS#9 attributes such as friendlyName (OID 1.2.840.113549.1.9.20) and
localKeyID (OID 1.2.840.113549.1.9.21) are commonly used to provide metadata
for keys and certificates within the container.
# ... and more
However since we are already talking about Libraries - Standard Java Crypto and
BouncyCastle have all this already inside. They are parsing the structures,
analyze and use it. So using one of these two would be the easiest solution
imho. I have never written a Detector so please excuse my ignorance:
{code:java}
public class PKCS12Detector implements Detector {
private static final long serialVersionUID = -8414458255467101503L;
private static final MediaType PKCS12_MEDIA_TYPE =
MediaType.application("x-pkcs12");
@Override
public MediaType detect(InputStream input, Metadata metadata) {
try {
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(input, null);
return PKCS12_MEDIA_TYPE; // success
}
catch (Exception e) {
return MediaType.OCTET_STREAM; // something else
}
}
} {code}
A bouncy castle one would look quite similar. Possible disadvantage: the
Keystore loading takes quite some time..
was (Author: tom_1st):
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
[jira] [Comment Edited] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file
[
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816811#comment-17816811
]
Lonzak edited comment on TIKA-3784 at 2/13/24 8:16 AM:
---
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
1.2.840.113549.1.9.21
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
1.2.840.113549.1.7.6
1.2.840.113549.1.7.1
1.2.840.113549.1.12.1.6
0x7F432D60BCD2888476E6CB9CD2BC69F1
2000
0x...(shortened fro readability)
0x0E8E4C15DCB1D87F
1.3.14.3.2.26
0x6DFFA14B5A8A32A87DAD2CFCE1EAEBDAFB89C897
0x826699C21B9A4C9E3E608D3C8FBD2310
2000
{code}
The oid is 3x in there - among others. The following things point to a pkcs12
format:
# Presence of PKCS#12-specific object identifiers (OIDs):
## PKCS#12 Bag Types: presence of OIDs such as 1.2.840.113549.1.12.10.1.x,
which indicate different types of key and certificate bags (KeyBags, CertBags,
etc.).
## PKCS#12 PbeIds: Encryption and hashing OIDs such as
1.2.840.113549.1.12.1.x, which indicate the use of specific encryption
mechanisms
# Use of encryption schemes:
## Recognize encryption schemes, especially those that are typical for
PKCS#12, such as pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd40BitRC2-CBC.
These schemes are crucial for the security of PKCS#12 files and a clear
indication of their presence.
# Structure of the file:
## Analyzing the file structure for multi-level nested SEQUENCE and
OCTET_STRING elements, which are typically used to store encrypted private keys
and certificates. The complexity of this structure is characteristic of PKCS#12
files.
# Specific attributes:
## PKCS#9 attributes such as friendlyName (OID 1.2.840.113549.1.9.20) and
localKeyID (OID 1.2.840.113549.1.9.21) are commonly used to provide metadata
for keys and certificates within the container.
# ... and more
However since we are already talking about Libraries - Standard Java Crypto and
BouncyCastle have all this already inside. They are parsing the structures,
analyze and use it. So using one of these two would be the easiest solution
imho. I have never written a Detector so please excuse my ignorance:
{code:java}
public class PKCS12Detector implements Detector {
private static final long serialVersionUID = -8414458255467101503L;
private static final MediaType PKCS12_MEDIA_TYPE =
MediaType.application("x-pkcs12");
@Override
public MediaType detect(InputStream input, Metadata metadata) {
try {
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(input, null);
return PKCS12_MEDIA_TYPE; // success
}
catch (Exception e) {
return MediaType.OCTET_STREAM; // something else
}
}
} {code}
A bouncy castle one would look quite similar - but currently I don't see any
advantage over the standard Java API. The only thing coming to mind is
performance: the Keystore loading using Standard Java takes quite some time.
Maybe BC has a better performance?
was (Author: tom_1st):
PKCS12 is not the easiest format :-|
The oid for pkcs12 starts with "1.2.840.113549.1.12"
I decoded one pkcs12 example (from redhat) and got the following:
{code:java}
3
1.2.840.113549.1.7.1
1.2.840.113549.1.7.1
1.2.840.113549.1.12.10.1.2
1.2.840.113549.1.12.1.3
0xC8CCE579B6DE5B393F7C4885714C04BA
2000
0x...(shortened fro readability)
1.2.840.113549.1.9.20
0x00630061
[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file
[
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816896#comment-17816896
]
Lonzak commented on TIKA-3784:
--
One other possibility would be to combine both approaches:
Usage of the current one which is quite fast to pre-categorize a file type.
Then if it is a security related file type then use the keystore method of Java
or BC to do the final determination...
> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found
> the following MIME magic which explains why I got these types back.
> {code:xml}
>
>
>
>
>
>
> mask="0x00FC" offset="0"/>
> mask="0xFC" offset="0"/>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867029#comment-17867029
]
Lonzak edited comment on TIKA-4194 at 7/18/24 2:48 PM:
---
The ticket was resolved with 2.9.2 - right?
So the version can be set and the ticket be closed... I would do that but don't
have the rights...
was (Author: tom_1st):
The ticket was resolved with 2.9.2 - right?
So the version can be set and the ticket be closed...
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),key
[jira] [Commented] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867029#comment-17867029
]
Lonzak commented on TIKA-4194:
--
The ticket was resolved with 2.9.2 - right?
So the version can be set and the ticket be closed...
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),key
[jira] [Created] (TIKA-4283) Add detection for JKS Keystore
Lonzak created TIKA-4283: Summary: Add detection for JKS Keystore Key: TIKA-4283 URL: https://issues.apache.org/jira/browse/TIKA-4283 Project: Tika Issue Type: New Feature Reporter: Lonzak Fix For: 2.9.3 [https://en.wikipedia.org/wiki/Java_KeyStore] The magic bytes are described here: [https://en.wikipedia.org/wiki/List_of_file_signatures] A proprietary keystore implementation provided by SUN. [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] If possible should (also) be added to 2.9.X Branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak resolved TIKA-4194.
--
Resolution: Fixed
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
> Fix For: 2.9.2
>
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
[jira] [Updated] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak updated TIKA-4194:
-
Fix Version/s: 2.9.2
(was: 2.9.3)
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
> Fix For: 2.9.2
>
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1
[jira] [Updated] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak updated TIKA-4194:
-
Fix Version/s: 2.9.3
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
> Fix For: 2.9.3
>
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12
[jira] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[ https://issues.apache.org/jira/browse/TIKA-4194 ]
Lonzak deleted comment on TIKA-4194:
--
was (Author: tom_1st):
The ticket was resolved with 2.9.2 - right?
So the version can be set and the ticket be closed... I would do that but don't
have the rights...
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
> Fix For: 2.9.2
>
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyL
[jira] [Closed] (TIKA-4194) tika fails to detect certain pkcs12 keystores types p12 pfx
[
https://issues.apache.org/jira/browse/TIKA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak closed TIKA-4194.
> tika fails to detect certain pkcs12 keystores types p12 pfx
> ---
>
> Key: TIKA-4194
> URL: https://issues.apache.org/jira/browse/TIKA-4194
> Project: Tika
> Issue Type: Bug
> Components: detector
>Affects Versions: 2.9.1
>Reporter: Lonzak
>Priority: Major
> Fix For: 2.9.2
>
>
> We use tika to detect the type of a file which is uploaded. In most cases
> this works quite well. However recently some files were rejected because tika
> reports an invalid file type. We'll get
> {code:java}
> APPLICATION/OCTET-STREAM{code}
> instead of
> {code:java}
> APPLICATION/X-X509-KEY{code}
> (As pointed out in TIKA-3784 the mimetype should really be
> "application/x-pkcs12" but for us "application/x-x509-key" works for now)
>
> I did an analysis and found that tika doesn't recognize certain types of
> pkcs12 keystores. The test keystores can be found
> [here|https://github.com/redhat-qe-security/keyfile-corpus/tree/master].
> I created a list to show which ones are effected. Out of 157 keystores 132
> are correctly detected and 25 are not.
>
> ||#||correct?||type||filename||
> |1|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |2|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|dsa(1024,sha1),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |3|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |4|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |5|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(none),key(none).p12|
> |6|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|ecdsa(P-256,sha256),cert(pbeWithSHAAnd40BitRC2-CBC,salt(8),iter(2048)),key(pbeWithSHAAnd3-KeyTripleDES-CBC,salt(8),iter(2048)),mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |7|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |8|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(0),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |9|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |10|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(16),iter(2048),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |11|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(64),iter(100),keyLen(default),prf(hmacWithSHA512)),aes-256-cbc(IV(16,mac(sha512,salt(64),iter(100)),pass(ascii).p12|
> |12|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |13|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(1),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |14|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),aes-128-cbc(IV(16,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |15|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(100),keyLen(default),prf(default)),des-ede3-cbc(IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |16|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(default)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |17|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(16),prf(hmacWithSHA256)),rc2-cbc(keyBits(56=128bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |18|OK|APPLICATION/X-X509-KEY;
> FORMAT=DER|rsa(2048,sha256),cert&key(PBES2(PBKDF2(salt(8),iter(2048),keyLen(5),prf(default)),rc2-cbc(keyBits(160=40bit),IV(8,mac(sha1,salt(8),iter(2048)),pass(ascii).p12|
> |19|OK|APPLICATION/X-X5
[jira] [Created] (TIKA-4285) Invalid Link for changelog CHANGES.txt files
Lonzak created TIKA-4285:
Summary: Invalid Link for changelog CHANGES.txt files
Key: TIKA-4285
URL: https://issues.apache.org/jira/browse/TIKA-4285
Project: Tika
Issue Type: Task
Affects Versions: 2.9.2, 2.9.1, 2.9.0
Reporter: Lonzak
On the tika [start page|https://tika.apache.org/] the linked change log files
CHANGES.txt starting with version 2.9.0 are missing/broken.
{+}Working{+}:
https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt
+Not working:+
https://archive.apache.org/dist/{-}{color:#FF}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
https://archive.apache.org/dist/{-}{color:#FF}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
https://archive.apache.org/dist/{-}{color:#FF}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TIKA-4285) Invalid Link for changelog CHANGES.txt files
[
https://issues.apache.org/jira/browse/TIKA-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak updated TIKA-4285:
-
Description:
On the tika [start page|https://tika.apache.org/] the linked change log files
CHANGES.txt starting with version 2.9.0 are missing/broken.
{+}Working{+}:
[https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt]
https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt
+Not working:+
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
https://archive.apache.org/dist/tika/3.0.0-BETA/CHANGES-3.0.0.txt
was:
On the tika [start page|https://tika.apache.org/] the linked change log files
CHANGES.txt starting with version 2.9.0 are missing/broken.
{+}Working{+}:
https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt
+Not working:+
https://archive.apache.org/dist/{-}{color:#FF}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
https://archive.apache.org/dist/{-}{color:#FF}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
https://archive.apache.org/dist/{-}{color:#FF}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
> Invalid Link for changelog CHANGES.txt files
>
>
> Key: TIKA-4285
> URL: https://issues.apache.org/jira/browse/TIKA-4285
> Project: Tika
> Issue Type: Task
>Affects Versions: 2.9.0, 2.9.1, 2.9.2
>Reporter: Lonzak
>Priority: Major
>
> On the tika [start page|https://tika.apache.org/] the linked change log files
> CHANGES.txt starting with version 2.9.0 are missing/broken.
>
> {+}Working{+}:
> [https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt]
> https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt
> +Not working:+
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
> https://archive.apache.org/dist/tika/3.0.0-BETA/CHANGES-3.0.0.txt
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TIKA-4285) Invalid Link for changelog CHANGES.txt files
[
https://issues.apache.org/jira/browse/TIKA-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lonzak updated TIKA-4285:
-
Description:
On the tika [start page|https://tika.apache.org/] the linked change log files
CHANGES.txt starting with version 2.9.0 are missing/broken.
{+}Working{+}:
[https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt]
[https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt]
+Not working:+
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
[https://archive.apache.org/dist/tika/3.0.0-BETA/CHANGES-3.0.0.txt]
+*Wrong Text*+ (as mention by Tilman)
15 July 2024: Apache Tika Release Apache Tika *3.0.0-BETA2* has been released!
This release includes several bug fixes and dependency upgrades. Please see the
[CHANGES.txt|https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt]
file for the full list of changes in the release and have a look at the
download page for more information on how to obtain{color:#FF} *Apache Tika
2.9.2.*{color}
was:
On the tika [start page|https://tika.apache.org/] the linked change log files
CHANGES.txt starting with version 2.9.0 are missing/broken.
{+}Working{+}:
[https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt]
https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt
+Not working:+
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
[https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
https://archive.apache.org/dist/tika/3.0.0-BETA/CHANGES-3.0.0.txt
> Invalid Link for changelog CHANGES.txt files
>
>
> Key: TIKA-4285
> URL: https://issues.apache.org/jira/browse/TIKA-4285
> Project: Tika
> Issue Type: Task
>Affects Versions: 2.9.0, 2.9.1, 2.9.2
>Reporter: Lonzak
>Priority: Major
>
> On the tika [start page|https://tika.apache.org/] the linked change log files
> CHANGES.txt starting with version 2.9.0 are missing/broken.
>
> {+}Working{+}:
> [https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt]
> [https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt]
> +Not working:+
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
> [https://archive.apache.org/dist/tika/3.0.0-BETA/CHANGES-3.0.0.txt]
>
> +*Wrong Text*+ (as mention by Tilman)
> 15 July 2024: Apache Tika Release Apache Tika *3.0.0-BETA2* has been
> released! This release includes several bug fixes and dependency upgrades.
> Please see the
> [CHANGES.txt|https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt]
> file for the full list of changes in the release and have a look at the
> download page for more information on how to obtain{color:#FF} *Apache
> Tika 2.9.2.*{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TIKA-4285) Invalid Link for changelog CHANGES.txt files
[
https://issues.apache.org/jira/browse/TIKA-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868003#comment-17868003
]
Lonzak commented on TIKA-4285:
--
Yes Tim, it is looking good now. Thank you as well!
> Invalid Link for changelog CHANGES.txt files
>
>
> Key: TIKA-4285
> URL: https://issues.apache.org/jira/browse/TIKA-4285
> Project: Tika
> Issue Type: Task
>Affects Versions: 2.9.0, 2.9.1, 2.9.2
>Reporter: Lonzak
>Assignee: Tim Allison
>Priority: Major
>
> On the tika [start page|https://tika.apache.org/] the linked change log files
> CHANGES.txt starting with version 2.9.0 are missing/broken.
>
> {+}Working{+}:
> [https://archive.apache.org/dist/tika/2.8.0/CHANGES-2.8.0.txt]
> [https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt]
> +Not working:+
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.0/CHANGES-2.9.0.txt
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.1/CHANGES-2.9.1.txt
> [https://archive.apache.org/dist/]{-}{color:#ff}release{color}{-}/tika/2.9.2/CHANGES-2.9.2.txt
> [https://archive.apache.org/dist/tika/3.0.0-BETA/CHANGES-3.0.0.txt]
>
> +*Wrong Text*+ (as mention by Tilman)
> 15 July 2024: Apache Tika Release Apache Tika *3.0.0-BETA2* has been
> released! This release includes several bug fixes and dependency upgrades.
> Please see the
> [CHANGES.txt|https://dist.apache.org/repos/dist/release/tika/3.0.0-BETA2/CHANGES-3.0.0-BETA2.txt]
> file for the full list of changes in the release and have a look at the
> download page for more information on how to obtain{color:#FF} *Apache
> Tika 2.9.2.*{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TIKA-4283) Add detection for JKS Keystore
[ https://issues.apache.org/jira/browse/TIKA-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated TIKA-4283: - Description: I added detection for java keystores JKS. It is based on the magic byte. Some additional infos: [https://en.wikipedia.org/wiki/Java_KeyStore] The magic bytes are described here: [https://en.wikipedia.org/wiki/List_of_file_signatures] A proprietary keystore implementation provided by SUN. [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] If possible this should (also) be added to 2.9.X Branch. was: [https://en.wikipedia.org/wiki/Java_KeyStore] The magic bytes are described here: [https://en.wikipedia.org/wiki/List_of_file_signatures] A proprietary keystore implementation provided by SUN. [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] If possible should (also) be added to 2.9.X Branch. > Add detection for JKS Keystore > -- > > Key: TIKA-4283 > URL: https://issues.apache.org/jira/browse/TIKA-4283 > Project: Tika > Issue Type: New Feature >Reporter: Lonzak >Priority: Major > Fix For: 2.9.3 > > > I added detection for java keystores JKS. It is based on the magic byte. > > Some additional infos: > [https://en.wikipedia.org/wiki/Java_KeyStore] > The magic bytes are described here: > [https://en.wikipedia.org/wiki/List_of_file_signatures] > > A proprietary keystore implementation provided by SUN. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] > > If possible this should (also) be added to 2.9.X Branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TIKA-4283) Add detection for JKS Keystore
[ https://issues.apache.org/jira/browse/TIKA-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated TIKA-4283: - Description: I added detection for java keystores JKS. It is based on the magic byte. Some additional infos: [https://en.wikipedia.org/wiki/Java_KeyStore] The magic bytes are described here: [https://en.wikipedia.org/wiki/List_of_file_signatures] A proprietary keystore implementation provided by SUN. [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] If possible this should be added to 2.9.X Branch. was: I added detection for java keystores JKS. It is based on the magic byte. Some additional infos: [https://en.wikipedia.org/wiki/Java_KeyStore] The magic bytes are described here: [https://en.wikipedia.org/wiki/List_of_file_signatures] A proprietary keystore implementation provided by SUN. [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] If possible this should (also) be added to 2.9.X Branch. > Add detection for JKS Keystore > -- > > Key: TIKA-4283 > URL: https://issues.apache.org/jira/browse/TIKA-4283 > Project: Tika > Issue Type: New Feature >Reporter: Lonzak >Priority: Major > Fix For: 2.9.3 > > > I added detection for java keystores JKS. It is based on the magic byte. > > Some additional infos: > [https://en.wikipedia.org/wiki/Java_KeyStore] > The magic bytes are described here: > [https://en.wikipedia.org/wiki/List_of_file_signatures] > > A proprietary keystore implementation provided by SUN. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation] > > If possible this should be added to 2.9.X Branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TIKA-4283) Add detection for JKS Keystore
[
https://issues.apache.org/jira/browse/TIKA-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868377#comment-17868377
]
Lonzak commented on TIKA-4283:
--
{noformat}
Done, it's now in 2.* as well, thanks.{noformat}
Highly appreciated. Thanks!
> Add detection for JKS Keystore
> --
>
> Key: TIKA-4283
> URL: https://issues.apache.org/jira/browse/TIKA-4283
> Project: Tika
> Issue Type: New Feature
> Components: core, parser
>Affects Versions: 2.9.2
>Reporter: Lonzak
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0, 2.9.3
>
>
> I added detection for java keystores JKS. It is based on the magic byte.
>
> Some additional infos:
> [https://en.wikipedia.org/wiki/Java_KeyStore]
> The magic bytes are described here:
> [https://en.wikipedia.org/wiki/List_of_file_signatures]
>
> A proprietary keystore implementation provided by SUN.
> [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation]
>
> If possible this should be added to 2.9.X Branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (TIKA-4283) Add detection for JKS Keystore
[
https://issues.apache.org/jira/browse/TIKA-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868377#comment-17868377
]
Lonzak edited comment on TIKA-4283 at 7/24/24 1:51 PM:
---
> Done, it's now in 2.* as well, thanks.
Highly appreciated. Thanks!
was (Author: tom_1st):
{noformat}
Done, it's now in 2.* as well, thanks.{noformat}
Highly appreciated. Thanks!
> Add detection for JKS Keystore
> --
>
> Key: TIKA-4283
> URL: https://issues.apache.org/jira/browse/TIKA-4283
> Project: Tika
> Issue Type: New Feature
> Components: core, parser
>Affects Versions: 2.9.2
>Reporter: Lonzak
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0, 2.9.3
>
>
> I added detection for java keystores JKS. It is based on the magic byte.
>
> Some additional infos:
> [https://en.wikipedia.org/wiki/Java_KeyStore]
> The magic bytes are described here:
> [https://en.wikipedia.org/wiki/List_of_file_signatures]
>
> A proprietary keystore implementation provided by SUN.
> [https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation]
>
> If possible this should be added to 2.9.X Branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
