Tech learning roadmaps…

[Yomama20]

On 3/2/2023 at 8:38 AM, dasari4kntr said:

 

https://drive.google.com/drive/folders/1-xCQsuoY2_5dZ52LKr2UZP3BP0Mcde4P?usp=sharing

 

ty bro

[dasari4kntr]

[dasari4kntr]

https://www.builder.io/blog/code-prefetching-is-a-lie

[8pm]

On 3/5/2023 at 6:51 PM, dasari4kntr said:

 

[dasari4kntr]

 

[Hindhustani]

HTTPS (HTTP Secure) is a protocol used to provide secure communication over the internet between a client (such as a web browser) and a server (such as a web server). Here's how HTTPS communication works between a client and a server:

1. The client initiates a connection to the server by sending a request to the server using the HTTPS protocol. The request includes the URL of the website the client wants to access.

2. The server responds by sending its SSL/TLS certificate to the client. The certificate contains the server's public key and is used to establish a secure connection between the client and server.

3. The client's browser verifies the SSL/TLS certificate to ensure that it is valid and belongs to the server. This involves checking the certificate's validity period, digital signature, and the certificate chain.

4. If the certificate is valid, the client's browser generates a symmetric encryption key and encrypts it using the server's public key. This ensures that only the server can decrypt the key.

5. The client's browser sends the encrypted symmetric key to the server.

6. The server decrypts the symmetric key using its private key.

7. The client's browser and the server use the symmetric key to encrypt and decrypt all data exchanged between them during the session. This includes the request and response data, headers, cookies, and any other information transmitted between them.

8. When the session is complete, the symmetric key is discarded and a new one is generated for the next session.

9. By using HTTPS, all data exchanged between the client and server is encrypted and cannot be intercepted by third parties. This helps to protect sensitive information such as login credentials, personal information, and financial data from being stolen or compromised during transit.


I am confused with 3 & 4 points. 

-- How does the server know if it is a good or bad client as long as both can generate the symmetric keys?. 
-- on what basis can the client validate the server certificate? What is the source that the client knows is a valid certificate sent by the server. 

for 9th point 

any request that is going through the browser, we can see the payload/requests by checking browser/ developer tools in the network tab then
how it is secure/encrypted both from the web browser and http call made from POSTMAN? 
 

@dasari4kntr @ramudu @Spartan@Vaampire   Can you help me to understand 3,4, 9 points above?

[dasari4kntr]

6 minutes ago, Hindhustani said:

HTTPS (HTTP Secure) is a protocol used to provide secure communication over the internet between a client (such as a web browser) and a server (such as a web server). Here's how HTTPS communication works between a client and a server:

1. The client initiates a connection to the server by sending a request to the server using the HTTPS protocol. The request includes the URL of the website the client wants to access.

2. The server responds by sending its SSL/TLS certificate to the client. The certificate contains the server's public key and is used to establish a secure connection between the client and server.

3. The client's browser verifies the SSL/TLS certificate to ensure that it is valid and belongs to the server. This involves checking the certificate's validity period, digital signature, and the certificate chain.

4. If the certificate is valid, the client's browser generates a symmetric encryption key and encrypts it using the server's public key. This ensures that only the server can decrypt the key.

5. The client's browser sends the encrypted symmetric key to the server.

6. The server decrypts the symmetric key using its private key.

7. The client's browser and the server use the symmetric key to encrypt and decrypt all data exchanged between them during the session. This includes the request and response data, headers, cookies, and any other information transmitted between them.

8. When the session is complete, the symmetric key is discarded and a new one is generated for the next session.

9. By using HTTPS, all data exchanged between the client and server is encrypted and cannot be intercepted by third parties. This helps to protect sensitive information such as login credentials, personal information, and financial data from being stolen or compromised during transit.


I am confused with 3 & 4 points. 

-- How does the server know if it is a good or bad client as long as both can generate the symmetric keys?. 
-- on what basis can the client validate the server certificate? What is the source that the client knows is a valid certificate sent by the server. 

for 9th point 

any request that is going through the browser, we can see the payload/requests by checking browser/ developer tools in the network tab then
how it is secure/encrypted both from the web browser and http call made from POSTMAN? 
 

@dasari4kntr @ramudu @Spartan@Vaampire   Can you help me to understand 3,4, 9 points above?

is this diagram helpful to you..?to  understand 3 and 4 points..?

 

[ramudu]

12 minutes ago, Hindhustani said:

HTTPS (HTTP Secure) is a protocol used to provide secure communication over the internet between a client (such as a web browser) and a server (such as a web server). Here's how HTTPS communication works between a client and a server:

1. The client initiates a connection to the server by sending a request to the server using the HTTPS protocol. The request includes the URL of the website the client wants to access.

2. The server responds by sending its SSL/TLS certificate to the client. The certificate contains the server's public key and is used to establish a secure connection between the client and server.

3. The client's browser verifies the SSL/TLS certificate to ensure that it is valid and belongs to the server. This involves checking the certificate's validity period, digital signature, and the certificate chain.

4. If the certificate is valid, the client's browser generates a symmetric encryption key and encrypts it using the server's public key. This ensures that only the server can decrypt the key.

5. The client's browser sends the encrypted symmetric key to the server.

6. The server decrypts the symmetric key using its private key.

7. The client's browser and the server use the symmetric key to encrypt and decrypt all data exchanged between them during the session. This includes the request and response data, headers, cookies, and any other information transmitted between them.

8. When the session is complete, the symmetric key is discarded and a new one is generated for the next session.

9. By using HTTPS, all data exchanged between the client and server is encrypted and cannot be intercepted by third parties. This helps to protect sensitive information such as login credentials, personal information, and financial data from being stolen or compromised during transit.


I am confused with 3 & 4 points. 

-- How does the server know if it is a good or bad client as long as both can generate the symmetric keys?. 
-- on what basis can the client validate the server certificate? What is the source that the client knows is a valid certificate sent by the server. 

for 9th point 

any request that is going through the browser, we can see the payload/requests by checking browser/ developer tools in the network tab then
how it is secure/encrypted both from the web browser and http call made from POSTMAN? 
 

@dasari4kntr @ramudu @Spartan@Vaampire   Can you help me to understand 3,4, 9 points above?

neeku ee comedy scene telusu kadha , Nag and Darmavarapu kalisinappudu , conversarion start chesee mundu , Darmavarapu code word aduguthadu , idhi kuda same ... "aakasam erraga undi" is the public key "adi desha drohula raktam valla vachina erupu" is private key , 

so when browser send request to server , server first send a public key and authority that issuesthe certificate  , browser verifies it (how it verifies is different path) and send confirmation to browser (refer @dasari4kntr answer / image for details ) .... thsi is called handshake 

one handshake established (in below comedy scene once nag and  Darmavarapu exchange the codes and confirm both knows each other) .... browser send thsi public key along with request , and on server side there is secure private key which can decrypt the message using the public and private key combinations ( simplifies version lo cheppa)

 

 

 

 

[Spartan]

@Hindhustani

SSL TLS handshake set ayye concept is point 3-4.

-- How does the server know if it is a good or bad client as long as both can generate the symmetric keys?. 

 Server will trust and initiate connection with any client to set up that handshake. Kaani once that handshake is setup (that is exchange of symmetric keys and session generation) a tarvata vere client vachi cannot continue the communication on same channel. this is happy path.

kaani man in the middle attack, Session hijacking comes into picture when the symmetric key or the session key is cracked. There are other ways to prevent that.

 

--- on what basis can the client validate the server certificate? What is the source that the client knows is a valid certificate sent by the server. 

Server send chese SSL certificate should always be provided by a trustworthy CA (Certificate Authority) like VeriSign, Amazon, Google etc. Client will be able to verify that certificate form the server.

Ala kaadu Self Signed certificates vadali ante, both Server and Client should have that certificates stored, for validating the connection. (not a widely used scenario, but konni companies intranet lo vadutai ilantivi).

[Spartan]

5 minutes ago, ramudu said:

neeku ee comedy scene telusu kadha , Nag and Darmavarapu kalisinappudu , conversarion start chesee mundu , Darmavarapu code word aduguthadu , idhi kuda same ... "aakasam erraga undi" is the public key "adi desha drohula raktam valla vachina erupu" is private key , 

so when browser send request to server , server first send a public key and authority that issuesthe certificate  , browser verifies it (how it verifies is different path) and send confirmation to browser (refer @dasari4kntr answer / image for details ) .... thsi is called handshake 

one handshake established (in below comedy scene once nag and  Darmavarapu exchange the codes and confirm both knows each other) .... browser send thsi public key along with request , and on server side there is secure private key which can decrypt the message using the public and private key combinations ( simplifies version lo cheppa)

 

 

 

 

exact ga ilanti example kosame vetukutununde to explain. and u posted it.   @ramudu

uncle and relative son madhya phone call

[Spartan]

for 9th point 

any request that is going through the browser, we can see the payload/requests by checking browser/ developer tools in the network tab then
how it is secure/encrypted both from the web browser and http call made from POSTMAN? 

 

Encrypted Data chudalevu, any browser or network tracer like Wireshark. On Network tab what you see is Request and response. (which are not encrypted, but binded to the cookies and sessions) .

[dasari4kntr]

9 minutes ago, ramudu said:

neeku ee comedy scene telusu kadha , Nag and Darmavarapu kalisinappudu , conversarion start chesee mundu , Darmavarapu code word aduguthadu , idhi kuda same ... "aakasam erraga undi" is the public key "adi desha drohula raktam valla vachina erupu" is private key , 

so when browser send request to server , server first send a public key and authority that issuesthe certificate  , browser verifies it (how it verifies is different path) and send confirmation to browser (refer @dasari4kntr answer / image for details ) .... thsi is called handshake 

one handshake established (in below comedy scene once nag and  Darmavarapu exchange the codes and confirm both knows each other) .... browser send thsi public key along with request , and on server side there is secure private key which can decrypt the message using the public and private key combinations ( simplifies version lo cheppa)

 

 

 

 

subject meeda ento grip vunte kaani inta simple gaa cheppaleru…

kudos…

[ramudu]

@Hindhustani

I am confused with 3 & 4 points. 

-- How does the server know if it is a good or bad client as long as both can generate the symmetric keys? -  it really doesn't care , if you get public key  and generate symmetric key and use that to encrypt your data and send to server , server can decrypt it because only private key can decrypt it ... browsers does this backend for us (encrypting data using symmetric key) ..... 

-- on what basis can the client validate the server certificate? What is the source that the client knows is a valid certificate sent by the server.  - issue authority , time , validity period and few other parameters , this certificate is digitally signed by issuing authority like RSA , DigiCert etc... , browser validate with those authorities 

for 9th point 

any request that is going through the browser, we can see the payload/requests by checking browser/ developer tools in the network tab then
how it is secure/encrypted both from the web browser and http call made from POSTMAN? --- when you see the data means it is not in transmit mode ,before data enter to network , data is encrypted by public / symmetric keys , once it is encryipted , you can still see it using network tools like wireshark in encrypted format but you can not edit it , if you edit decryption with private key fail ... that is the whole concept of encryption here 
 

[ramudu]

6 minutes ago, Spartan said:

exact ga ilanti example kosame vetukutununde to explain. and u posted it.   @ramudu

uncle and relative son madhya phone call

[ramudu]

2 minutes ago, dasari4kntr said:

subject meeda ento grip vunte kaani inta simple gaa cheppaleru…

kudos…

mee daggara nerchukunee bro