Security Blog

The latest news and insights from Google on security and safety on the Internet

Changes to our SSL Certificates

23 maggio 2013
Share on Twitter Share on Facebook
Google

10 commenti :

Chris Lockfort ha detto...

With an apparent move to having a wide variety of CA vendors / leaf certs / etc, won't that make it harder for people to recognize when, for instance, a government forces a CA to issue valid certs for domains like gmail.com and intercepts what they presumed were private communications?

24 maggio 2013 alle ore 10:37
Unknown ha detto...

... and certainly you should use sha-256 instead of sha-1 in your certificates

27 maggio 2013 alle ore 06:37
The IT Solutions People ha detto...

I think it will be completely safe. Private key's are not something that a CA has or ever should have possession of so unless Google themselves provide their private key's willingly to government's all information remains private.

29 maggio 2013 alle ore 13:48
The IT Solutions People ha detto...

It is about time that Google moved to 2048 bit Roots and Keys. The continued use of the archaic Equifax Root signed hierarchy was a poor example to businesses and Enterprises on how to use SSL certificates to ensure the integrity of private and sensitive data and the legitimacy of the supposedly secured URL

SSL certificates are not used to protect Google themselves but the Public that interacts with Google, with the complete and unequivocal expectation that their Private and Sensitive data will remain just that.

Our core business principles are based on this message and this is the guidance that itsolutionspeople.com provide to its customers.

29 maggio 2013 alle ore 14:09
April Joy ha detto...

Is there a list of SSL compliant vendors out there?

19 giugno 2013 alle ore 15:12
Unknown ha detto...

To answer April Joy;
Symantec, GeoTrust, Thawte, Trustwave
http://goo.gl/RKaaVE

12 agosto 2013 alle ore 17:03
pseudo nym ha detto...

Even with the expansion to 2048 bit keys, if the entropy generating the primes P and Q used for the encryption is too low, there are still issues. See the great research done by the University of Michigan about "minding your Ps and Qs" - one start point here - https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/

So Google...do you have sufficient entropy? That's the real question. 1024 bit keys would theoretically have enough primes that there would never be an issue of duplicate keys, but poor random number generation and insufficient entropy led to the Michigan folks compromising about a half a percent of public keys. That is vastly more than predicted...

23 agosto 2013 alle ore 13:10
Unknown ha detto...

When can we expect to see updated Google applications that support these recommendations?

At this time, Google Drive's PC application does not support SNI and performs some degree of certificate pinning for transfers.

30 settembre 2013 alle ore 10:14
global protect ha detto...

Multi-domain SSL certificates refer to a specific type of SSL certificate that offer security to multiple domain and hostnames that exist within the same domain. Multi-domain certificates are occasionally referred to as unified communications certificate (UCC), multi-SAN or UC certificate. This certificate is perfect for Exchange Server 2010, Microsoft Live Communications Software, and Microsoft Exchange Server 2007.

21 dicembre 2013 alle ore 13:29
Unknown ha detto...

We all know what's wrong and don't care, how do we get a new certificate from Google?

10 maggio 2014 alle ore 07:57

Posta un commento

  

Etichette


  • #sharethemicincyber
  • #supplychain #security #opensource
  • android
  • android security
  • android tr
  • app security
  • big data
  • biometrics
  • blackhat
  • C++
  • chrome
  • chrome enterprise
  • chrome security
  • connected devices
  • CTF
  • diversity
  • encryption
  • federated learning
  • fuzzing
  • Gboard
  • google play
  • google play protect
  • hacking
  • interoperability
  • iot security
  • kubernetes
  • linux kernel
  • memory safety
  • Open Source
  • pha family highlights
  • pixel
  • privacy
  • private compute core
  • Rowhammer
  • rust
  • Security
  • security rewards program
  • sigstore
  • spyware
  • supply chain
  • targeted spyware
  • tensor
  • Titan M2
  • VDP
  • vulnerabilities
  • workshop


Archive


  •     2025
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2024
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2023
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2022
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2021
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2020
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2019
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2018
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2017
    • dic
    • nov
    • ott
    • set
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2016
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2015
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2014
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • apr
    • mar
    • feb
    • gen
  •     2013
    • dic
    • nov
    • ott
    • ago
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2012
    • dic
    • set
    • ago
    • giu
    • mag
    • apr
    • mar
    • feb
    • gen
  •     2011
    • dic
    • nov
    • ott
    • set
    • ago
    • lug
    • giu
    • mag
    • apr
    • mar
    • feb
  •     2010
    • nov
    • ott
    • set
    • ago
    • lug
    • mag
    • apr
    • mar
  •     2009
    • nov
    • ott
    • ago
    • lug
    • giu
    • mar
  •     2008
    • dic
    • nov
    • ott
    • ago
    • lug
    • mag
    • feb
  •     2007
    • nov
    • ott
    • set
    • lug
    • giu
    • mag

Feed

Follow
Give us feedback in our Product Forums.
  • Google
  • Privacy
  • Terms