Client-driven randomized and changing media access control (mac) address (rcm) mechanism
US-2024422202-A1 · Dec 19, 2024 · US
US9537899B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-9537899-B2 |
| Application number | US-201213408225-A |
| Country | US |
| Kind code | B2 |
| Filing date | Feb 29, 2012 |
| Priority date | Feb 29, 2012 |
| Publication date | Jan 3, 2017 |
| Grant date | Jan 3, 2017 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Techniques described herein enable a client to store information indicating whether various hosts (e.g., servers, web domains) support a preferred security protocol, such as a False Start-modified TLS or SSL protocol. The client may then use this information to dynamically determine whether to use the preferred protocol when connecting to a particular host. When the client attempts a handshake to establish a secure connection with a host for the first time, the client does so using the preferred protocol. If the handshake fails, the client locally stores domain or other identifying information for the host so that the client may employ a non-preferred protocol in subsequent connection attempts. Thus, a client may avoid performance degradation caused by attempting a preferred-protocol connection with a host that does not support the preferred protocol. Stored information may include a time stamp enable periodic checks for host capability updates.
Opening claim text (preview).
What is claimed is: 1. A computer-implemented method comprising: determining that a secure connection was not successfully established between a client and a server using a first security protocol, wherein the first security protocol includes an abbreviated handshake; at least in part based on determining that the secure connection was not successfully established using the first security protocol, storing to memory on the client information identifying the server as a server that does not support the first security protocol; and at least in part based on determining that the secure connection was not successfully established using the first security protocol, attempting to establish the secure connection between the client and the server using a second security protocol that includes an unabbreviated handshake. 2. The method of claim 1 , wherein the first security protocol is a Secure Sockets Layer (SSL) that supports False Start or a Transport Layer Security (TLS) protocol that supports False Start, and wherein the second security protocol is a SSL that does not support False Start or a TLS protocol that does not support False Start. 3. The method of claim 1 , wherein the information is stored in temporary storage on the client. 4. The method of claim 1 , wherein the information is stored in persistent storage on the client. 5. The method of claim 1 , wherein the information is stored on the client in a database that identifies one or more domains that do not support the first security protocol. 6. The method of claim 5 , wherein the information further includes, for each of the one or more domains, a time stamp indicating a date and a time when the information of the respective domain was stored in the database. 7. The method of claim 1 , further comprising: during an attempt to establish a subsequent secure connection between the client and the server, accessing the information stored on the client; determining that the server does not support the first security protocol based at least partly on the information; and based on determining that the server does not support the first security protocol, attempting to establish the subsequent secure connection using the second security protocol without attempting to establish the subsequent secure connection using the first security protocol. 8. The method of claim 1 , further comprising: during an attempt to establish a subsequent secure connection between the client and the server, accessing the information stored on the client; determining that the information stored on the client includes expired information for the server; and attempting to establish the subsequent secure connection using the first security protocol. 9. One or more computer storage media storing instructions that, when executed by at least one processor, instruct the processor to perform actions comprising: receiving an indication that a secure connection is to be established between a client and a server; accessing information in storage on the client device, in advance of attempting to establish the secure connection, the information identifying the server as a server that does not support a preferred security protocol, wherein the preferred security protocol includes an abbreviated handshake; and at least in part in response to accessing the information identifying the server as the server that does not support the preferred security protocol, establishing the secure connection using a non-preferred security protocol that includes an unabbreviated handshake and wherein the unabbreviated handshake employs a greater number of round trip communications than the abbreviated handshake to establish a communications session. 10. The one or more computer storage media of claim 9 , wherein the preferred security protocol is a Secure Sockets Layer (SSL) that supports False Start or a Transport Layer Security (TLS) protocol that supports False Start, and wherein the non-preferred security protocol is a SSL that does not support False Start or a TLS protocol that does not support False Start. 11. The one or more computer storage media of claim 9 , wherein the actions further comprise determining that the information identifying the server as the server that does not support the preferred security protocol is expired based on a time stamp stored with the information identifying the server as the server that does not support the preferred security protocol and indicating a date and a time when the information identifying the server as the server that does not support the preferred security protocol was stored in the database. 12. The one or more computer storage media of claim 9 , wherein the information identifying the server as the server that does not support the preferred security protocol is in temporary storage on the client to establish secure connections within a same communications session. 13. The one or more computer storage media of claim 9 , wherein the information identifying the server as the server that does not support the preferred security protocol is in persistent storage on the client to establish secure connections across different communications sessions. 14. The one or more computer storage media of claim 9 , wherein the information identifying the server as the server that does not support the preferred security protocol includes a domain of the server. 15. The one or more computer storage media of claim 9 , wherein the preferred security protocol enables the client to begin sending application data to the server before the client has received a Finished message from the server, and the non-preferred protocol does not enable the client to begin sending application data to the server before the client has received the Finished message from the server. 16. A client device comprising: at least one processor; and memory storing computer-readable instructions executable by the at least one processor to perform operations including: attempting to establish a secure connection between the client device and a server using a first security protocol that supports False Start; determining whether the secure connection was successfully established using the first security protocol; based on a determination that the secure connection was not successfully established using the first security protocol, storing information on the client device identifying the server as not supporting False Start; and re-attempting to establish the secure connection between the client device and the server using a second security protocol that does not support False Start. 17. The client device of claim 16 , wherein the information identifying the server as not supporting False Start is stored on a database in the memory of the client device. 18. The client device of claim 16 , further comprising a hard drive, wherein the information identifying the server as not supporting False Start is stored in persistent storage on the hard drive. 19. The client device of claim 16 , wherein at least a portion of the computer-readable instructions stored in the memory comprise a web browser application. 20. The client device of claim 16 , wherein the operations further include: subsequently receiving an indication that a subsequent secure connection is to be established between the client device and the server; accessing the stored information to determine whether the server does not support False Start; based on a determination that the stored information indicates that the server does not support False Start an
involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved (negotiation of communication capabilities H04L69/24) · CPC title
at the transport layer · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.