summaryrefslogtreecommitdiffstats
path: root/security-utils
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Enable TLSv1.3 for Vespa mTLS"Henning Baldersheim2023-03-251-7/+10
|
* Enable TLSv1.3 for Vespa mTLSBjørn Christian Seime2023-03-241-10/+7
|
* Implement RFC 9180 HPKE sender asymmetric key authentication modeTor Brede Vekterli2023-03-234-13/+195
| | | | | | | | We already have support for the `base` unauthenticated mode, so this just adds the `auth` mode where the sender's key pair is added to the ECDH shared key derivation mix. This ensures that a message may only be successfully opened if the sender was in possession of the private key (`skS`) corresponding to the expected public key (`pkS`).
* Merge pull request #26168 from ↵Tor Brede Vekterli2023-02-242-2/+4
|\ | | | | | | | | vespa-engine/revert-26152-revert-26139-vekterli/add-content-state-api-capability Reapply: add `vespa.content.state_api` capability"
| * Revert "Revert "Add `vespa.content.state_api` capability" MERGEOK"Tor Brede Vekterli2023-02-232-2/+4
| |
* | Revert "Revert "Store original capability (set) names from JSON config in ↵Bjørn Christian Seime2023-02-236-25/+72
|/ | | | PeerPolicy" MERGEOK"
* Merge pull request #26153 from vespa-engine/revert-26145-bjorncs/capabilitiesBjørn Christian Seime2023-02-236-72/+25
|\ | | | | Revert "Store original capability (set) names from JSON config in PeerPolicy" MERGEOK
| * Revert "Store original capability (set) names from JSON config in PeerPolicy"Bjørn Christian Seime2023-02-236-72/+25
| |
* | Revert "Add `vespa.content.state_api` capability"Bjørn Christian Seime2023-02-232-4/+2
|/
* Merge pull request #26139 from ↵Tor Brede Vekterli2023-02-222-2/+4
|\ | | | | | | | | vespa-engine/vekterli/add-content-state-api-capability Add `vespa.content.state_api` capability
| * Add `vespa.content.state_api` capability to JavaTor Brede Vekterli2023-02-222-2/+4
| | | | | | | | Add new capability to existing `vespa.telemetry` capability set.
* | Store original capability (set) names from JSON config in PeerPolicyBjørn Christian Seime2023-02-226-25/+72
|/ | | | Add additional helper methods to convert `names <=> capabilities`.
* Grant container nodes access to container document apiBjørn Christian Seime2023-02-201-1/+2
|
* Specify that '/logs' requires logserver capabilityBjørn Christian Seime2023-02-171-1/+2
|
* Warn instead of fail for unknown capability (set)Bjørn Christian Seime2023-02-172-9/+10
|
* Improve metric names, fix wiringBjørn Christian Seime2023-02-161-9/+9
|
* Add capability 'vespa.sentinel.inspect_services'Bjørn Christian Seime2023-02-161-0/+1
|
* Add metrics for capability checksBjørn Christian Seime2023-02-162-0/+39
|
* Add capability 'vespa.content.proton_admin_api'Bjørn Christian Seime2023-02-151-0/+1
|
* Add slobrok capability to all application nodesBjørn Christian Seime2023-02-151-2/+2
|
* Add new capabilities to existing capability setsBjørn Christian Seime2023-02-151-6/+10
|
* Use explicit `equals` and `hashCode` to use contents of arrays, not just refsTor Brede Vekterli2023-02-142-0/+55
| | | | Also add a friendlier `toString()` that hex dumps the enc/ciphertext fields.
* Require capabilities for built-in request handlersBjørn Christian Seime2023-02-141-0/+4
|
* Revert "Revert "Bjorncs/capabilities""Henning Baldersheim2023-02-145-21/+34
|
* Revert "Bjorncs/capabilities"Henning Baldersheim2023-02-145-34/+21
|
* Add new capabilities in node specific capability setsBjørn Christian Seime2023-02-133-11/+24
|
* Rename 'from()' to 'of()'Bjørn Christian Seime2023-02-135-10/+10
|
* Define required capabilities for existing JRT RPC methodsBjørn Christian Seime2023-02-091-0/+12
|
* Introduce capbilities for unclassified APIsBjørn Christian Seime2023-02-091-0/+3
| | | | Require 'vespa.rpc.unclassified' by default for all JRT APIs
* Move definition of predefined capability set to parent classBjørn Christian Seime2023-02-094-30/+46
| | | | Introduce functional interface ToCapabilitySet to simplify construction of second order capability sets.
* Add 'vespa.none' capabilityBjørn Christian Seime2023-02-061-0/+1
|
* Add an "interactive" token resealing protocol and basic tooling supportTor Brede Vekterli2023-01-314-10/+197
| | | | | | | | | | | | | | Implements a protocol for delegated access to a shared secret key of a token whose private key we do not possess. This builds directly on top of the existing token resealing mechanisms. The primary benefit of the resealing protocol is that none of the data exchanged can reveal anything about the underlying secret. Security note: neither resealing requests nor responses are explicitly authenticated (this is a property inherited from the sealed shared key tokens themselves). It is assumed that an attacker can observe all requests and responses in transit, but cannot modify them.
* Add y64 encoderBjørn Christian Seime2023-01-302-0/+65
|
* Unify on Streams.toListHenning Baldersheim2023-01-175-10/+5
|
* Ensure that HTTPS clients only use allowed ciphers and protocol versionsBjørn Christian Seime2023-01-092-2/+25
|
* Revert "Ensure that HTTPS clients only use allowed ciphers and protocol ↵Andreas Eriksen2023-01-062-25/+2
| | | | versions" (#25436)
* Ensure that HTTPS clients only use allowed ciphers and protocol versionsBjørn Christian Seime2023-01-062-2/+25
|
* Use ChaCha20-Poly1305 instead of AES-GCM for shared key-based cryptoTor Brede Vekterli2023-01-055-24/+228
| | | | | | | | | | | | | | | | | | | | | This is to get around the limitation where AES GCM can only produce a maximum of 64 GiB of ciphertext for a particular <key, IV> pair before its security properties break down. ChaCha20-Poly1305 does not have any practical limitations here. ChaCha20-Poly1305 uses a 256-bit key whereas the shared key is 128 bits. A HKDF is used to internally expand the key material to 256 bits. To let token based decryption be fully backwards compatible, introduce a token version 2. V1 tokens will be decrypted with AES-GCM 128, while V2 tokens use ChaCha20-Poly1305. As a bonus, cryptographic operations will generally be _faster_ after this cipher change, as we use BouncyCastle ciphers and these do not use any native AES instructions. ChaCha20-Poly1305 is usually considerably faster when running without specialized hardware support. An ad-hoc experiment with a large ciphertext showed a near 70% performance increase over AES-GCM 128.
* Correct class name to reflect actual cipher name orderTor Brede Vekterli2022-12-015-8/+8
| | | | No functional changes, just bugged me to have used the wrong order.
* Use correct encoding base in testTor Brede Vekterli2022-11-281-2/+2
| | | | Wrong base was "close enough" that test seemingly worked most of the time...!
* Use BouncyCastle AES GCM cipher and I/O streams instead of JCATor Brede Vekterli2022-11-163-25/+90
| | | | | | | | | | | | | | | | | | This resolves two issues: * `javax.crypto.OutputCipherStream` swallows MAC tag mismatch exceptions when the stream is closed, which means that corruptions (intentional or not) are not caught. This is documented behavior, but still very surprising and a rather questionable default. BC's interchangeable `CipherOutputStream` throws as expected. To avoid regressions, add an explicit test that both ciphertext and MAC tag corruptions are propagated. * The default-provided `AES/GCM/NoPadding` `Cipher` instance will not emit decrypted plaintext per `update()` chunk, but buffer everything until `doFinal()` is invoked when the stream is closed. This means that decrypting very large ciphertexts can blow up memory usage since internal output buffers are reallocated and increased per iteration...! Instead use an explicit BC `GCMBlockCipher` which has the expected behavior (and actually lets cipher streams, well, _stream_). Add an `AeadCipher` abstraction to avoid leaking BC APIs outside the security module.
* Add support for token resealingTor Brede Vekterli2022-11-112-4/+28
| | | | | | | | | Adds underlying support--and tooling--for resealing a token for another recipient. This allows for delegating decryption to another party without having to reveal the private key of the original recipient (or having to send the raw underlying secret key over a potentially insecure channel). Key ID can/should change as part of this operation.
* Use Base62 for tokens and Base58 for keysTor Brede Vekterli2022-11-094-11/+55
| | | | | | | | * Base62 minimizes extra size overhead relative to Base64. * Base58 removes ambiguous characters from key encodings. Common for both bases is that they do not emit any characters that interfer with easily selecting them on web pages or in the CLI.
* Add a codec that enables conversion to and from a base N representationTor Brede Vekterli2022-11-084-0/+316
| | | | | | | | | | | | | Adds a codec that enables easy conversion from an array of bytes to any numeric base in [2, 256) and back again, using a supplied custom alphabet. Implemented by treating the input byte sequence to encode verbatim as a big-endian `BigInteger` and iteratively doing a `divmod` operation until the quotient is zero, emitting the modulus mapped onto the alphabet for each iteration. Decoding reverses this process, ending up with the same `BigInteger` as in the initial encoding step.
* Array clone() -> Arrays.copyOf()Tor Brede Vekterli2022-11-022-2/+2
|
* Encapsulate key identifier in own objectTor Brede Vekterli2022-11-025-60/+205
| | | | Enforces invariants and avoids having to pass raw byte arrays around.
* Let token key IDs be UTF-8 byte strings instead of just an integerTor Brede Vekterli2022-11-013-37/+119
| | | | | | | | | | | | | | This makes key IDs vastly more expressive. Max size is 255 bytes, and UTF-8 form is enforced by checking that the byte sequence can be identity-transformed to and from a string with UTF-8 encoding. In addition, we now protect the integrity of the key ID by supplying it as the AAD parameter to the key sealing and opening operations. Reduce v1 token max length of `enc` part to 255, since this is always an X25519 public key, which is never bigger than 32 bytes (but may be _less_ if the random `BigInteger` is small enough, so we still have to encode the length).
* Add basic tooling for public key encryption and decryptionTor Brede Vekterli2022-10-271-0/+1
| | | | | | | Adds support for: * X25519 key pair generation * HPKE stream encryption with public key and token generation * HPKE stream decryption with private key
* Use JDK17's own hex utilities instead of BouncyCastle'sTor Brede Vekterli2022-10-254-73/+66
|
* Use HPKE instead of ECIES for shared single-use keysTor Brede Vekterli2022-10-203-88/+65
| | | | | Also use AES-128 instead of AES-256 for the one-time key since the underlying HPKE AEAD cipher protecting the key itself is AES-128.