Jump to content
People were interested in these podcasts
Play Episode
25min
Podcasting Tech
Mastering Podcast Discoverability and Audience Insights with Arielle Nissenblatt of Earbuds Podcast Collective
Ever wonder how you stumbled upon your favorite podcast? Was it by a friend's recommendation or a happy accident? In this episode, we dive deep into the world of podcast discoverability and audience engagement—two essentials for any podcaster looking to grow their reach and captivate listeners.Our guest is none other than Arielle Nissenblatt, the powerhouse behind the Earbuds Podcast Collective and a board member of the Podcast Academy. Arielle is a trailblazer in the podcasting space, with unique insights on how to help your podcast stand out and build a loyal following.A passionate advocate for podcasting, Arielle founded the Earbuds Podcast Collective—a newsletter dedicated to thoughtful podcast recommendations. Her experience and role at the Podcast Academy have positioned her as a go-to authority on effective podcast strategies, making her an invaluable resource for both seasoned podcasters and newcomers alike.In This Episode, We Cover:Arielle's Podcast Journey: From her early days as a podcast fan to becoming a respected industry expert.The Story Behind Earbuds Podcast Collective: Discover the mission of Earbuds and how it has become a key platform for podcast recommendations.Strategies for Podcast Discoverability: Explore Arielle’s insights on multi-channel discoverability and how to leverage personalized recommendations to reach the right audience.Amplifying Listener Growth: Learn the best techniques for promoting your show, sustaining growth, and using social proof to enhance your podcast’s appeal.Audience Engagement 101: Tips for connecting with listeners, fostering loyalty, and growing your community.Choosing a Podcast Hosting Provider: A breakdown of hosting options to help you find the perfect fit for your show.Resources and Links from the Episode:Earbuds Podcast Collective: earbuds.audioListen to Who Weekly: Who Weekly PodcastFollow Arielle on Twitter: @arithisandthatFollow Arielle on Instagram: @ariellethisandthatFollow Arielle on Linkedin: Arielle Ni
In the Flat
Episode 129: Week two look back and week three look ahead
We talk about all of the week 2 results, buy or sell playoff contenders, and preview week 3 in College Football. The poor state of Notre Dame (01:01) Texas vs. Michigan Results (04:55) Iowa State vs. Iowa Results (09:49) Tennessee vs. NC State Results (13:36) Nebraska vs. Colorado Results (18:20) Oregon vs. Boise State Results (23:58) Buy or Sell: Oklahoma State as Playoff Contender (30:03) Buy or Sell: Kansas State as Playoff Contender (30:42) Buy or Sell: Penn State as Playoff Contender (31:50) Buy or Sell: Utah as Playoff Contender (33:19) Buy or Sell: Alabama as Playoff Contender (34:34) Buy or Sell: LSU as Playoff Contender (36:41) Buy or Sell: Oklahoma as Playoff Contender (38:50) Arizona at Kansas State Preview (41:25) Alabama at Wisconsin Preview (42:57) LSU at South Carolina Preview (45:45) Boston College at Missouri Preview (47:14) Oregon at Oregon State Preview (48:47) Tulane at Oklahoma Preview (50:43) Follow us on Twitter - https://twitter.com/InTheFlatPod Check out our new website - https://intheflatpod.podcastpage.io/ Get 10% off your first month of BetterHelp by using our link– BetterHelp.com/InTheFlat
Garden Report | Celtics Post Game Show from TD Garden
Celtics Sell Team For Record Breaking 6.1 Billion Dollars
Bill Chisholm, managing partner at Symphony Technology Group, has agreed to buy the Boston Celtics from the Grousbeck family at a record $6.1 billion valuation, sources tell ESPN. This marks the largest sale of a sports franchise in North American history. CLNS Media's Bobby Manning and John Zannis go LIVE on The Garden Report to react. The Garden Report on CLNS Media is Powered by: 💰 Prize Picks - https://prizepicks.onelink.me/LME0/CLNS Download the app today and use Code CLNS when you sign up & Get $50 instantly when you play $5! 🎫 Gametime - https://gametime.co Take the guesswork out of buying NBA tickets with Gametime. Download the Gametime app, create an account, and use code CLNS for $20 off your first purchase. Download Gametime today. Terms apply. What time is it? Gametime! Join Our Discord Server: https://clnsmedia.com/discord Learn more about your ad choices. Visit megaphone.fm/adchoices
WSJ What’s News
Bonds Sell Off as New U.S. Tariffs Upend Global Trade
A.M. Edition for April 9. As U.S. tariffs targeting nearly 100 nations take effect, WSJ reporters Jason Douglas and Kim Mackrael explain how America’s trade partners are responding to the levies, including a 104% tariff on China. Plus, markets reporter Chelsey Dulaney breaks down an intensifying selloff in usual safe haven U.S. Treasurys. And President Trump vows to bring back the declining U.S. coal industry. Luke Vargas hosts. Sign up for the WSJ’s free What’s News newsletter. Learn more about your ad choices. Visit megaphone.fm/adchoices

Tech learning roadmaps…


dasari4kntr

Recommended Posts

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?

Link to comment
Share on other sites

  On 3/26/2023 at 2:29 AM, 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?

Expand  

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

 

FV0DW-WUAAA9621?format=jpg&name=4096x409

Link to comment
Share on other sites

  On 3/26/2023 at 2:29 AM, 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?

Expand  

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)

 

 

 

 

  • Haha 1
  • Upvote 1
Link to comment
Share on other sites

@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).

Link to comment
Share on other sites

  On 3/26/2023 at 2:49 AM, 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)

 

 

 

 

Expand  

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

uncle and relative son madhya phone call :D

Link to comment
Share on other sites

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) .

Link to comment
Share on other sites

  On 3/26/2023 at 2:49 AM, 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)

 

 

 

 

Expand  

subject meeda ento grip vunte kaani inta simple gaa cheppaleru…

kudos…

Link to comment
Share on other sites

@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 
 

  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...