ALTS will be stable API soon. It will be supported and available for use if
you are running on GCP. However, ALTS is by design for GCP only.
If you want to run outside GCP, you can use TLS. We have new TlsCredentials
API in grpc c++, which supports SPIFFE.
On Tuesday, January 21, 2020 at
We have implemented in hot credential reloading in grpc core under
grpc_tls_spiffe credentials. We are in the middle of wrapping with C++ so
that C++ caller can use it. It should be ready this Q3.
On Friday, August 16, 2019 at 6:55:48 PM UTC-7, Jeff wrote:
>
> I am interested in the answer to
Thank you very much for keeping us in the loop.
Could you please email detailed vulnerabilities to the private
grpc-secur...@googlegroups.com list? Production security engineers will
evaluate the vulnerability within 3 workdays.
gRPC CVE process can be found in
You can begin with this example
https://github.com/grpc/grpc/issues/9593
On Saturday, August 3, 2019 at 6:42:26 PM UTC-7, Jeff wrote:
>
> Are there any client/server examples of mutual TLS authentication in C++?
> thanks!
--
You received this message because you are subscribed to the Google
We don't have any concrete plan to support OCSP in grpc core.
One plan we have is to support handshaker model, where there is a
handshaker server that does all the SSL work (key management, revocation,
rotation, handshake, session resumption and caching, and so on). gRPC just
needs to
gRPC currently does not support Windows credential store as root
certificate.
gRPC ships with its own root certificate (from mozilla). Of course, user
can provide his/her own root certificates.
For Linux, gRPC will uses system root store. We don't have such support for
MacOS and Windows.
On
I would like to understand your setting better. Does your client present a
certificate?
If client does not have a certificate, you could
use GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE.
When client presents a certificate to server, server needs to verify the
certificate that is chained back to
If you do not want to use SslTargetNameOverride, the other alternative is
using SPIFFE credential in gRPC. This work is coming soon (estimate by the
end of this year).
https://github.com/grpc/proposal/pull/98
https://github.com/grpc/grpc/pull/16614#pullrequestreview-179042959
In SPIFFE
Which platform does your client run? Looks like MacOS.
For Linux, we support read from grpc system root store. For MacOS, it is
not support yet -- grpc only reads default root from root pem certificates
shipped with grpc.
However, there are a few other ways to load root certificates. E.g., you
Sorry, we do not have plan to support ALTS outside GCP.
On Tuesday, October 16, 2018 at 5:52:21 AM UTC-7, aaj...@gmail.com wrote:
>
> I would be interested in ALTS outside of GCP. Are there any plans to make
> a public version of the other components/services required to run ALTS in a
> private
I am confused why you need SNI in this case. You uri is the hostname with
port.
You can just use
channel = grpc.secure_channel(uri, creds)
without SNI. It should work. The reason is that uri will be plumbed to grpc
core. When grpc checks server hostname in grpc_ssl_host_matches_name(), the
In grpc c core and wrapped languages, the only way to set SNI is to
use GRPC_SSL_TARGET_NAME_OVERRIDE_ARG.
See
https://github.com/grpc/grpc/blob/master/test/core/end2end/h2_ssl_cert_test.cc#L176
for example.
Not sure about this python error though.
On Thursday, September 20, 2018 at 5:55:52
Ruslan,
I want to understand more of your use case on hostname override. Is it used
in testing? What is in the server's TLS certificate? Hostname or server
identity or server's IP address?
For workload-to-workload communication, I suggest you use SPIFFE type
credentials in the gRFC, in such
Thanks Yihua for clarification.
TLS server authorization is client-side enhancement. It is that client
checks whether server is authorized to run the service (based on target
name and server's identity).
In the near future, we will propose and implement server-side client
authorization check
Arpit,
Could you please patch https://github.com/grpc/grpc/pull/15143 and see
whether it solves your problem.
On Friday, April 20, 2018 at 9:30:34 AM UTC-7, Arpit Baldeva wrote:
>
> I am on 1.0.2k so yeah it is a problem on that version.
>
> I think the simplest fix is what I mentioned in last
Could you describe the race condition in details?
In gRPC ssl_transport_security, init_openssl() is only called when ssl
transport security is needed. In your application, you are
calling SSL_library_init() in a separate thread in parallel?
On Wednesday, April 18, 2018 at 2:46:28 PM UTC-7,
Best,
> Colin
>
> On Wed, Apr 18, 2018 at 4:52 PM, jiangtao via grpc.io <
> grp...@googlegroups.com > wrote:
>
>> Hi Colin,
>>
>> In the Istio scenario, if an application needs to call Google APIs, my
>> understanding is that it does not connect to loc
rialized properly on
> every request). Again, this isn't the end of the world, but it's certainly
> not going to help me build a better application.
>
> I'm definitely interested in staying updated on this discussion.
>
> Best,
> Coiln
>
> On Wed, Apr 4, 2018 at 7:10
Hi Arpit,
grpc_init initializes OpenSSL for a short period (~2 days) and the code was
later removed. Do you still the problem, if you fetch the latest master?
On Monday, April 16, 2018 at 2:22:32 PM UTC-7, Arpit Baldeva wrote:
>
> Hi,
>
> I recently pinned down a sporadic race condition in my
+ ejona@
gRPC-java does support CallCredentials over insecure channel previously,
but not any more.
All the tokens for accessing Google cloud services require protection of
the tokens. Keep in mind that attacker can use the stolen token for
impersonation. For user defined tokens, you can
So far ALTS is for GCP use only. Let me discuss with my management to see
whether we can provide an easy interface to use "pluggable" handshaker
service. If so, we may expose API to choose either google default
handshaker service or pluggable handshaker service. Google default
handshaker
Hi Ruslan,
ALTS is not ready for public consumption yet. We could expose ALTS to early
access customers.
Note that at this point, ALTS is for use inside GCP, such as authentication
between two workloads running on GCP or for faster access of Google cloud
services on GCP.
So far we do not
This feature is not supported in gRPC c core right now. I have created an
issue for tracking this feature.
https://github.com/grpc/grpc/issues/14216
On Friday, January 26, 2018 at 12:04:37 PM UTC-8, chris@gmail.com wrote:
>
> They keys are in PEM format. I'm unsure if they were converted
23 matches
Mail list logo
