Wednesday, April 22, 2026

GIT Basics

April 22, 2026 0



 GitHub: It is a cloud based platform which provides distributed version control and source management system.

Alternative source mangement system:

  • Github
  • Bitbucket
  • GitLab
  • SVN
GIT Algorithm:
It will hash out of content (produces 40 char hex string)
It will create a file name same as hash
Zip up with your content and stored inside of file.
#git add test.txt
#cat test.txt | git hash-object --stdin
blob:
It is convert a file into hash file.
Hash algorithm will create a hash file according the file contents. It will not create a two dfferent hashing file if both both files are having a same contents.
#git write-tree : It will display the tree structure of GIT
#git cat-file -p hashfile : Read a content inside of hashfile
Git Commit:

Commit is a copy of snapshot. It will create a read only file whenever we performed a commit. The previous content or update will be there and would not be destroyed,
Merkle Tree: A tree structure in which each leaf node is a hash of a block data and non leaf node is a hash of its children.
Head:

Merge:
It merge one or more commit into branch.



Tags # DevOps # Git Continue Reading
at No comments:
Tags ,

Monday, April 20, 2026

Go Language

April 20, 2026 0


Go is an open source and compiled programming language. It is developed at Google to build, reliable software.
why do we need GO?
* Compiles to native code
* Type safe - We have to declare before use a variable
* Garbage collector - It will allocate and deallocate a GC by automatically.
Every Go source file is part of a package.
We have to import when do we call other package in your program
The main function is called hen a program first starts..
Go fmt utility:
It will fix the code style automatically.
Go run utility:
* It compiles a Go source file and runs it.
Go build - It compile Go source file into an executable
Calling Function:
package main

import (
"fmt"
"math"
)

func main() {
fm.Println(math.Floor(1))
fmt.Println("Hello")
}

}

Pointers:
We can use pointers to fix of calling a double functions.
func main() {
    amount:=6
    double(&amount)
    fmt.println(amount)
}
func double(number * int) {
    *number *=2
}

Tags # Go Continue Reading
at No comments:
Tags

Monday, April 6, 2026

Optimizing AI models for Production Environment

April 06, 2026 0

 



We can LLMs in three ways by usually

1. Encode text into semantic vectors with little/no file tuning
2. Fine tune a pre-trained LLM to perform a very specific task using by Transfer Learning
3. Query an LLM to solve a task which was pre-trained or could intuit.
Two types of LLMs now.
1) Auto encoding LLMs - Learn a entire sequence by predicting tokens (words) given past and future context.   It is best for classification and embedding + retrieval tasks. [Example BERT]
2) Auto regressive LLMs : It will predict a future token 
LLMs excel at task that require reasoning using context and input information in the conjunction to produce a nuanced answer.


AI agents are semi autonomous systems that interact with environment, make decisions and perform tasks on behalf of users.
Autonomy - They can perform tasks without continuous human intervention.
Decision Making - Use data to analyze and choose actions
Adaptability - Learn and improve over time with feedback.
Optimizing Models:
Speculative Decode : Using an assistant model to guide next token perdition
Caching OS models : Implementing prompt caching with open Source models
Quantization : Reducing computation requirement of neural network.
Distillation : Transfer knowledge from large model into small through targeted fine tuning.
Speculative Decoding:
Assistant agent calls for forward method of calling [calling parameter over and over again].  The main model simply verifies which token is agreed with request.





Tags # AI # LLM # OPenAI Continue Reading
at No comments:
Tags , ,

Saturday, April 4, 2026

Deep Dive of Kubernetes Network

April 04, 2026 0

 

K8S is a dynamic network. Pods are ephemeral.  IP change on every restart.

Containers with in the pod shared a single network namespace.

K8S networking Model:

1) Every Pod receive a unique and cluster wide IP address.

2) All pods on the same node can communicate directly without NAT

3) All pods on different nods can communicate directly without NAT

4) A Pod self seen IP is identical to the IP other pods use to reach it [Flat network]

Kubernetes specifies what is required and CNI plugins decide How to implement it

Communication pattern in K8S

Container to Container - within same pod via loopbackup [127.0.0.1]

Pod to Pod - Direct IP communication across nodes without address translation

Pod to Service - Kube proxy intercepts traffic and load balancing to healthy end points

External to Service - Exposed via NodePort, LoadBalance type or Ingress controller

Node to Pod - Kubelet and monitoring agents


Kube-Proxy:
Kube proxy runs on every node as a DaemonSet and part of the Kubernetes control plane. It watches API sever for any change of resource or end points. API server initate a end point object when selector create a resourece.  Kube proxy is maintaining a chain of IP table mode. I used to maintain local and forward routing.  IPVS is a kernel level virutal load balancer. It will handle thousand of service request and routing at a same time.
Pod to service will take care of kube proxy and pod to pod communication will take care of CNI.
CoreDNS:
CoreDNS is the cluster DNS server and deployed as a deployment in the kube system namespace.Every pod of /etc/resolv.conf is inject to point into CoreDNS.
Pod Networking:
Each pod has an Own network namespace and fully isolated stack. The namespace contain virutal vNICs, routing table and iptable rules.

Infra [pause] container creates and own a network namespace for the pod. All application containers in the Pod share the Infra container namespace at startup.

Virtual [veth] pair : Two virtual NICs connect between Pod and Node side. One end lives inside the Pod's network namespace [eth0] and other end is attached to Node like linux bridge [cbr0]

Traffic flow : Pod [eth0] -> veth pair -> host bridge -> node routing table -> destination 

Cross Node communication:
Node to Node communication is used Overlay approach and Underlay approach.
Overlay approach is encapsulated a traffic and decapsulated from destionation node.
Underlay approach is a direct routing method.
Modern CNIs like calico & cilium will support both approach.
Overlay (VxLAN/Geneve) - It is universal compatibility and cloud friendly. It will support upto 50 bytes per packet if MTU set to 1450
Underlay - It required physical network to accept and route through BGP routing

Analysis a packet flow under flannel CNI.

controlplane:~$ kubectl get pods -n kube-flannel -o wide

NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES

kube-flannel-ds-5sv5v   1/1     Running   0          15m    controlplane   <none>           <none>

kube-flannel-ds-n7dxx   1/1     Running   0          15m     node01         <none>           <none>

controlplane:~$ 

node01:~$ tcpdump -i flannel.1 -n 'tcp' -vvv

tcpdump: listening on flannel.1, link-type EN10MB (Ethernet), snapshot length 262144 bytes

^C

0 packets captured

0 packets received by filter

0 packets dropped by kernel

node01:~$ 

Service:

K8S will face very difficult to manage an IP address across PODs. This issue will fix by service which providing an stable virtual IP (Cluster IP). It will act as a load balancer across all the pods. It will enable a loose coupling within application.

Service components:

Selector : Determines which pods belongs to this service
Cluster IP: Virtual IP assigned by K8S
Port: The port of the service listens on
TargetPort: The port on the container that the service forwards traffic to
Endpoints: The actual pod IPs and ports maintained by the endpoint controller
Metadata: Name, namespace, and labels for the identification and discovery
DNS Service:
CoreDNS will create a DNS record for service by automatically
FQDN format: <Service name>.<namespace>.svc.cluster.local
Short names: same namespace can be used as <servicename>
Search Domains: Kubernetes injects search paths for automatic resolution
A Records : Return the ClusterIP for standard Service lookup
SRV Records: For advanced applications needing protocol and port information
Kube-Proxy:
It is running as DameonSet on every Node and responsible for Service networking
Use Linux Kernel iptables rules for packet filtering and NAT
CoreDNS Configuration:
ConfigMap-based : All configuration in /etc/coredns/Corefile ConfigMap
plugins : Support for various plugins [K8S, etcd, forward]
Zone Configuration : Define which domains Core DNS manages
Upstream DS : can forward unknown queries to external DNS servers
Caching : Caches DNS responses to reduce latency and load
Logging : Can enable query logging for troubleshooting
Common issues related to Services:
Service is not reachable - We need to verify the selector label should match with Pod labels.
Some Pods are not receiving traffic - Validate the pod readiness status and liveness probes.
DNS is not resolving - We need to validate the CoreDNS in kube-system namespace
High Latency - Validate the kube-proxy mode, It may be iptables overhead
Uneven load distribution : Check pod resources and scheduling across nodes
Service IP not allocated : Verify Cluster IP range configured and available
Deployment Methods:
Multi tier applications : Cluster IP for backend and LoadBalancer for frontend
Hybrid deployments: Database might be deployed in cloud and services were deployed in Local
Blue-Green deployment : The customer has 2 types of setups for Prod, They will tested in standby before applied in active production environment.
Canary Deployments : They will segregate a loads through LoadBalancer and send 10% of loads into latest deployment.
Service Mesh Integration : Using Services as foundation for advanced networking
Multi-cluster : Services can be federated across multiple clusters.
Created service with Cluster IP for Web application:
ontrolplane:~$ kubectl get pods -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
web-64c966cf88-45528   1/1     Running   0          20s   10.244.1.5   node01   <none>           <none>
web-64c966cf88-4x8xq   1/1     Running   0          20s   10.244.1.4   node01   <none>           <none>
web-64c966cf88-n66tm   1/1     Running   0          20s   10.244.1.3   node01   <none>           <none>
controlplane:~$ kubectl expose depolyment web --name=web-service --t^C
controlplane:~$ kubectl expose deployment web --name=web-service --type=ClusterIP --port=80 --target-port=80
service/web-service exposed
controlplane:~$ kubectl describe service web-service
Name:                     web-service
Namespace:                default
Labels:                   app=web
Annotations:              <none>
Selector:                 app=web
Type:                     ClusterIP
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.97.253.216
IPs:                      10.97.253.216
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
Endpoints:                10.244.1.3:80,10.244.1.4:80,10.244.1.5:80
Session Affinity:         None
Internal Traffic Policy:  Cluster
Events:                   <none>
Created a test CoreDNS service and validate with Cluster IP address of Web application:
ontrolplane:~$ kubectl run -it --image=nicolaka/netshoot --restart=Never test-dns -- sh
All commands and output from this session will be recorded in container logs, including credentials and sensitive information passed through the command prompt.
If you don't see a command prompt, try pressing enter.
~ # nslookup web-service
;; Got recursion not available from 10.96.0.10
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   web-service.default.svc.cluster.local
Address: 10.97.253.216
;; Got recursion not available from 10.96.0.10
Ingress and Ingress Controller:
Ingress controller continuously monitor the Kubernetes API for Ingress, Service and Secret changes.
Configuration Generation : Controller will generate a configuration for underlying of Load Balancer  if detect any changes in API and.
Configuration Push : Updated configuration is applied to the actual load balancer or reverse proxy daemon.
Health Checks: Controllers verify backend services are healthy and update routing accordingly
Event-Driven: Entire process is asynchronous and event driven.
Backward Compatibility : Controller will ensure that exist traffic is not disrupted during configuration changes.
NGINX Ingress Controller:
* Most widely adopted controller in production and maintained by the community and NGINX.
* NGINX open source reverse proxy as the underlying HTTP/HTTPS server
* Rich Feature Set: Rate limiting, request/response rewriting, WAF integration, mutual TLS, JWT validation
Traefik - Modern & Cloud Native Option
* It is build for Kubernetes and microservice. It doesn't require service reboot while ingress configure changes.
* Buit-in Web UI and REST API for monitoring and management
* Powerful middleware chain for request transformation
* Lower memory and CPU consume compare to NGINX.
Other Popular Ingress Controller:
AWS ALB Controller : Provision AWS application Load Balancers directly, native AWS integration.
GCP Load Balancing : Google Cloud's integrated solution with advanced routing and DDoS protection
Azure App Gateway:  Microsoft managed ingress solution with WAF and SSL offloading
Istio Ingress Gateway: Service mesh approach, combines ingress with advanced traffic management and security policies
Cilium Ingress Controller: eBPF based controller, ultra high performance and advanced networking features.
Configure TLS in Ingress resources:
TLS Block Structure : Specify hosts, Secret Name and optional Paths.
tls:
- hosts:
    - api.test.com
    - web.test.com
  secretName: my-tls-secret
Secret Format: Kubernetes TLS secrets contain tls.cert and tls.key [private key] as base64 encoded data
Hostname Matching: TLS certificate hostname must match the Ingress host specification, mismatches cause browser warning.
Wildcard Certificate : Support *.test.com to serve multiple subdomains with single certificate
Mixed protocol : It can serve simultaneously for HTTP and HTTPS.
Controller Specific : Different controllers may support additional TLS features vis annotations
Advanced Routing Patterns:
Header based routing : Route based on HTTP headers controller
Query parameter Routing : Some controllers support routing based on query parameters
Weight Based Routing - Distribute traffic percentage wise across multiple backends
Request Transformation : Add/modify headers, append/strip paths before sending to backend services
Rate Limiting : Limit request per IP, hostname or custom key
Authentication/Authorization : Some controllers will support JWT validation, OAuth flows or mutual TLS verification at ingress.
Gateway API:
K8S is having limited Ingress by design. Gateway API will use to over limit of Ingress. It has a three Layers. 1) GatewayClass (controller implementation) 2) Gateway (listener and security config) 3) HTTPRoute (routing rules)
HTTPRoute is similar to Ingress rules but more flexible and reusable across multiple Gateways.
Create an Ingress controller:
controlplane:~$ kubectl create namespace ingress-ngnix
namespace/ingress-ngnix created
controlplane:~$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/baremetal/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created

controlplane:~$ kubectl create namespace ingress-ngnix
namespace/ingress-ngnix created
controlplane:~$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/baremetal/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created

controlplane:~$ kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-wjmb8        0/1     Completed   0          29s
ingress-nginx-admission-patch-nvst7         0/1     Completed   0          29s
ingress-nginx-controller-5c5949d455-8zn8s   1/1     Running     0          29s
controlplane:~$ kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.110.76.184    <none>        80:30384/TCP,443:32500/TCP   61s
ingress-nginx-controller-admission   ClusterIP   10.105.205.149   <none>        443/TCP                      61s
controlplane:~$ kubectl create deployment nginx-app --image=nginx --replicas=2 -n test
error: failed to create deployment: namespaces "test" not found
controlplane:~$ kubectl create ns test
namespace/test created
controlplane:~$ kubectl create deployment nginx-app --image=nginx --replicas=2 -n test
deployment.apps/nginx-app created
controlplane:~$ kubectl expose deployment nginx-app --name=nginx-service --port=80 --target-port=80 -n test
service/nginx-service exposed
controlplane:~$ kubectl get pods -n test
NAME                         READY   STATUS    RESTARTS   AGE
nginx-app-766796df68-826f9   1/1     Running   0          56s
nginx-app-766796df68-ggz4p   1/1     Running   0          56s
controlplane:~$ kubectl get svc -n test
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
nginx-service   ClusterIP   10.97.195.253   <none>        80/TCP    52s
controlplane:~$ kubectl get svc -n test -o wide
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE     SELECTOR
nginx-service   ClusterIP   10.97.195.253   <none>        80/TCP    2m43s   app=nginx-app
controlplane:~$ 

controlplane:~$ kubectl apply -f ingress-host-based.yaml 
ingress.networking.k8s.io/host-based-ingress created
controlplane:~$ kubectl get ingress -n test
NAME                 CLASS   HOSTS         ADDRESS       PORTS   AGE
host-based-ingress   nginx   nginx.local   172.16.20.6   80      33s
controlplane:~$ kubectl describe ingress host-based-ingress -n test
Name:             host-based-ingress
Labels:           <none>
Namespace:        test
Address:          
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host         Path  Backends
  ----         ----  --------
  nginx.local  
               /   nginx-service:80 (10.244.1.6:80,10.244.1.7:80)
Annotations:   <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    67s (x2 over 67s)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    10s                nginx-ingress-controller  Scheduled for sync
controlplane:~$ 
Network Policy:
K8S API objects that act as Layer 3/4 firewalls and controlling pod-to-pod and pod-to-external communication.
Security Model: It will deny by default, we can define explicitly allow what's needed.
Container Network Interface (CNI) : K8S delegates network implementation to CNI plugins.
It will act as OR operation if multiple entries. It will allow traffic to any matching destination is allowed simultaneously.
Microservice Policy:
3 Tier Architecture : Web (frontend), API (backend), Database (persistent layer)
Traffic Flow: Client -> web:80, Web -> API:8080, API -> Database:5432
Policy Layer 1:  Web pods have egress to API pods on port 8080, deny all other egress exceptDNS
Policy Layer 2: API pods have ingress from web pods on 8080 and egress to Database pods on 5432 and deny all else.
Policy Layer 3: Database pods have ingress from API pods on 5432 only and never initiates outbound
Debugging of Network policy:
  • Connection Timeout/ Refused : Check if a policy is selecting the pod and list polices in the namepsace.
  • List policy - kubect get networkpolicy -n namespace | grep pod-label
  • Describe policy - kubectl describe networkpolicy name -n namepsace
  • check pod labels : kubectl get pods -n namespace --show-labels
  • Test connectivity : kubectl exec source-pod -- curl destination-pod:port -v
  • Check for DNS issues - If application cannot resolve hostnames, policy may missing egress of that host.
  • CNI logs: kubectl logs -n kube-system calico-node/cilium-agent | grep DENIED

Tags # DevOps # K8S Continue Reading
at No comments:
Tags ,

Sunday, March 22, 2026

LLM Context management along with Cursor 2.0

March 22, 2026 0

 

Cursor 2.0 is an AI editor for Production Environment. It will be run 8 parallel agents without any issue. 

Context Management like telling story when it getting convoluted. It will direct path when AI get confused.

Context window is a windows chat where user and AI interact each other.






AI driven project initialization:

1) Describe - Describe your problem or expectation
2) Define - Stack, database, auth & deployment
3) Generate - Cursor will take care of codes



 

Tags # AI # LLM Continue Reading
at No comments:
Tags ,

Tuesday, March 10, 2026

Infrastructure as Code through AI workloads

March 10, 2026 0



A Kubernetes operator is a specialized controller designed to extend Kubernetes API, enabling the management of complex application through declarative configurations.
Kubernetes Operator operate within continuous reconciliation loop. This cycle begins when user create a resource, It prompting controller to monitoring a change and take a necessary action to ensure a desire state. Operator allow user to defined a desired state of application in custom resources, while operator
controller continue reconcile the actual state with this desire state, embodying the operational expertise of human site reliability engineer.
KubeFlow : It is a primary of orchestration tool for MI workflow. It is focus on training aspect of models.

Most using of Kubernetes resources in the real time.
APIService
ClusterRole
ClusterRoldBinding
ConfigMap
CronJob
CSIDriver
CSINode
DaemonSet
Deployment
EphemeralContainers
HorizontalPodAutoscalar
Ingress
IngressClass
Job
Namespace
Node
PersistVolume
Pod
PodDisruptionBudget
PodTemplate
ReplicatSet
ResourceQuota
Role
RoleBinding
Secret
Service
ServiceAccount
StatefulSet
StorageClass
VolumeAttachment
Binding
CertificateSigningRequest
ComponentStatus
ControllerRevision
CustomResourceDef
Endpoints
EndpointSlice
LeaseReplicationController
LimitRange
LocalSubjectAccess
MutatingWebhookConfiguration
NetworkPolicy
PodSecurityPolicy
PriorityClass
RuntimeClass
SelfSubjectAccess
SelfSubjectRules
SubjectAccessReview
TokenReview
ValidatingWebhook



Tags # AI # K8S # Kubeflow Continue Reading
at No comments:
Tags , , , ,

Monday, March 2, 2026

TLS 1.3 Cipher Suite

March 02, 2026 0

 



TLS1.3 is released in August 2018 (RFC8446).  It is a latest version of Transport Layer Protocol. It will remove a weaker algorithms and improve a speed of authentication. 

TLS 1.2 Cipher suit diagram:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Key Exchange[DHE], Authentication [RSA], Encryption [AES_256_CBC] and Hashing [SHA]

TLS1.3 will support 5 Cipher suites compare to TLS.2 will support of multiple Cipher suites.

TLS1.3 including 5 Cipher Suites:
  • TLS_AES_128_GCM_SHA256 [Must Implement]
  • TLS_AES_256_GCM_SHA384 [Should be Implement]
  • TLS_CHACHA2-_POLY305_SHA256 [Should be implement]
  • TLS_AES_128_CCM_SHA256 [Can implement]
  • TLS_AES_128_CCM_8_SHA256 [Can implement]
It will follow up with forward secrecy [Once Encrypted always encrypted]
TLS1.3 will remove a custom DH Groups and support a standard based group only, because it will lead may insecure groups being used and breach a security.
DH means Diffi-Hellman starts with agreeing upon some values.
Approved DH groups are designated via various standards.
* Traditional DH groups : RFC 2409 & RFC 3526
* Elliptic Curve Groups : RFC 5639, FIPS 186-4

Handshake method of TLS 1.2 Vs 1.3


TLS1.2 is using 2routing method for handshake a request, but TLS1.3 is using 1 routing method for handshake method. It will improve a quick response compare to TLS1.2.
TLS1.2 is created 4 keys while handshake connection.
  • Client encryption
  • Client HMAC
  • Server Encryption
  • Server HMAC

 TLS1.3 will create a 11 keys while handshakes connection request.

TLS workflow:
* TLS/SSL will send a highest support version of client Hello and Sever Hello for handshake.
Middlebox or Load balancer will drop a request if mismatch of version upto TLS1.2.
TLS1.3 will create a header with TLS1.0 , Client hello version with TLS 1.2 and Client hello extension with TLS1.3, Hence the request will not drop off in between Middlebox.
* TLS is providing forward end-to-end handshake encryption. Handshake will create a session keys which project an application data. Session keys will be derived from RSA & DS.
DS - It will share public key store and private key will delete after SEED establishment. It will support of forward Secrecy.

Client Hello is carrying on information about Version, Session ID and Cipher suites.
Below diagram will give a details about 11 keys of TLS1.3.



Tags # Authentication # TLS1.3 Continue Reading
at No comments:
Tags ,