Missing Tls in Echo Go
How Missing Tls Manifests in Echo Go
Missing TLS in Echo Go applications creates a critical attack surface that exposes sensitive data in transit. When Echo Go servers listen on HTTP instead of HTTPS, attackers can intercept API calls using simple network sniffing tools like Wireshark or tcpdump. This is particularly dangerous for Echo Go applications handling authentication tokens, API keys, or personal data.
The most common manifestation occurs when developers use Echo Go's default HTTP server configuration without enabling TLS. Consider this vulnerable Echo Go setup:
package main
import (
"github.com/labstack/echo/v4"
"github.com/labstack/echo/v4/middleware"
)
func main() {
e := echo.New()
e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.GET("/api/users", getUsers)
e.POST("/api/auth", authenticate)
e.Start(":8080") // HTTP only - vulnerable!
}
func getUsers(c echo.Context) error {
// Returns user data - transmitted in plaintext
return c.JSON(200, map[string]interface{}{
"users": []string{"alice", "bob", "charlie"},
})
}
func authenticate(c echo.Context) error {
// Accepts credentials - transmitted in plaintext
return c.JSON(200, map[string]interface{}{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
})
}This configuration exposes several attack vectors specific to Echo Go applications:
- Man-in-the-middle attacks on authentication endpoints, allowing credential theft
- Session hijacking through exposed JWT tokens in Authorization headers
- API key exposure in request headers or query parameters
- Data exfiltration from API responses containing sensitive information
- Credential stuffing attacks using harvested authentication data
Echo Go's middleware ecosystem can compound this vulnerability. If you're using middleware like JWT authentication, CORS, or rate limiting without TLS, attackers can bypass security controls by intercepting and modifying requests. The Echo Go framework's default behavior of serving HTTP on port 8080 (or the specified port) without TLS enforcement makes this a common oversight.
Echo Go-Specific Detection
Detecting missing TLS in Echo Go applications requires both manual inspection and automated scanning. For manual detection, examine your Echo Go application's main function and server initialization code. Look for the Start() method calls without TLS configuration:
// Vulnerable - no TLS
func main() {
e := echo.New()
e.GET("/api/data", getData)
e.Start(":8080") // HTTP only
}Safe configuration should use StartTLS() or StartAutoTLS() methods:
// Secure - TLS enabled
func main() {
e := echo.New()
e.GET("/api/data", getData)
e.StartTLS(":443", "cert.pem", "key.pem") // TLS with custom certs
}Automated detection with middleBrick is particularly effective for Echo Go applications. middleBrick's black-box scanning approach tests the actual running API without requiring source code access. The scanner attempts HTTPS connections and analyzes response headers to detect missing TLS:
$ middlebrick scan https://your-echo-api.com
✅ Authentication: B (BOLA risks found)
✅ Input Validation: C (potential injection points)
❌ TLS/Encryption: F (HTTP endpoints detected, no TLS)
Summary:
- Risk Score: 62/100 (D grade)
- Critical Finding: Missing TLS on all endpoints
- Recommendation: Enable TLS with valid certificatesmiddleBrick's TLS detection specifically checks for:
- HTTP vs HTTPS protocol usage
- Certificate validity and expiration
- HTTP Strict Transport Security (HSTS) headers
- Certificate chain completeness
- Supported TLS versions and cipher suites
For Echo Go applications, middleBrick also analyzes OpenAPI specifications if provided, cross-referencing documented endpoints with actual TLS implementation. This is particularly useful for Echo Go APIs using automatic OpenAPI generation through middleware like echo-swagger.
Echo Go-Specific Remediation
Remediating missing TLS in Echo Go applications involves configuring proper TLS termination and certificate management. The most straightforward approach is using Echo Go's built-in TLS support with StartTLS():
package main
import (
"github.com/labstack/echo/v4"
"github.com/labstack/echo/v4/middleware"
)
func main() {
e := echo.New()
e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.GET("/api/users", getUsers)
e.POST("/api/auth", authenticate)
// TLS with certificate files
certFile := "server.crt"
keyFile := "server.key"
e.StartTLS(":443", certFile, keyFile)
}
func getUsers(c echo.Context) error {
return c.JSON(200, map[string]interface{}{
"users": []string{"alice", "bob", "charlie"},
})
}
func authenticate(c echo.Context) error {
return c.JSON(200, map[string]interface{}{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
})
}For development environments or when Let's Encrypt certificates aren't available, Echo Go supports automatic TLS via Let's Encrypt with StartAutoTLS():
func main() {
e := echo.New()
e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.GET("/api/users", getUsers)
e.POST("/api/auth", authenticate)
// Automatic TLS with Let's Encrypt
email := "admin@yourdomain.com"
e.StartAutoTLS(":443", email)
}Echo Go also integrates well with reverse proxy setups where TLS termination occurs at the proxy level (nginx, Caddy, cloud load balancers). In this configuration, Echo Go runs on HTTP internally while the proxy handles TLS:
// Echo Go running behind reverse proxy
func main() {
e := echo.New()
e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.GET("/api/users", getUsers)
e.POST("/api/auth", authenticate)
// Run on HTTP - proxy handles TLS
e.Start(":8080")
}For comprehensive security, combine TLS with Echo Go's middleware ecosystem:
func main() {
e := echo.New()
e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
AllowOrigins: []string{"https://yourdomain.com"},
AllowMethods: []string{http.MethodGet, http.MethodPost},
}))
e.GET("/api/users", getUsers)
e.POST("/api/auth", authenticate)
// TLS with HSTS header
e.Use(middleware.HTTPSRedirect())
e.StartTLS(":443", "cert.pem", "key.pem")
}Remember to update your OpenAPI specifications and client documentation to reflect the HTTPS endpoints, and implement proper certificate rotation policies for production deployments.
Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |