MICHAEL REBER
I am a Linux Enthusiast IT Security Engineer Ethical Hacker
About Me.
Senior Linux Security Engineer / Pentester and Developer
As a dedicated unix system engineer and security specialist, I am always interested in the latest topics in the entire field of information technology and therefore always keep my knowledge up to date. I have had the opportunity to demonstrate my know-how and actively support various major customers in Switzerland, including SBB, Post AG, VBS / FUB, Netcloud, IWB, IDW, EBL and A.Vogel. (A few of many)
One of the key elements in IT is security. It's true, because a company or a system is only as secure as its weakest asset. That's why I also develop solutions for myself and my customers that offer the greatest security in terms of the usability of an infrastructure. Some example would be SIEM and XDR systems based in Elasticsearch. I have now more than 14 years experience in IT-Security, Linux Engineering and Hardening. I run my own private cloud as well as two wiki instances, one public and the other is private. My main goal is to let you benefit from my experience and deep knowledge as well.
Personal Information
- Name Michael Reber
- Alias Michu
- Residence Bern, Switzerland
- Email michu[@]michu-it.com
- Consulting Yes, for companies as well as private persons
- Languages German, English, Bash, Ansible, PHP, Python and Golang
FURTHER EXPERIENCE / KNOW HOW
Linux / Windows
Debugging and problem-solving. Best-Practises, repairing and configuration management of various services. Malware prevention and removal, as well as protection of your own data. And so much more...
IT-Security
Hardening of your existing infrastructure; Linux and Windows. Configuration of Web-Application Firewalls based on Mod Security. Setting up hardened reverse proxies with TLS encryption and header security. - Establishing Log-Management, SIEM and XDR systems.
Web Development
Creation of templates or brandings for company applications or CMS systems as well as creating own contend management systems according to the needs of the customers.
Hardware / Soldering
Repairing and maintaining of hardware of any kind. Whether defective smartphones, notebooks, graphics cards or even microwaves. Soldering own devices and building up circuits.
SSH PUBLIC KEY
Contact me.
michu[@]michu-it.com
michael-reber-844b2695
Bern, Switzerland
Whois Query
Cert Transp
Enter a domain name (e.g., "ricardo.ch") to search certificate transparency logs. Stay patient this can take a while.
?What are Certificate Transparency Logs?
Certificate Transparency (CT) logs are publicly accessible databases that store records of TLS (Transport Layer Security) certificates issued by Certificate Authorities (CAs). TLS certificates are essential for establishing secure connections on the internet, as they verify the identity of a website and encrypt data transmitted between a server and a client. When a TLS certificate is issued, it is added to a CT log, which is a public record of certificates tied to a domain name.
The primary goal of CT logs is to improve security and transparency in the certificate issuance process. By making certificate records publicly accessible, CT logs allow anyone—from companies and security researchers to the general public—to monitor which certificates have been issued for their domains. This visibility makes it easier to detect potentially fraudulent or misissued certificates, ensuring that a company's online identity is protected against misuse by attackers posing as legitimate websites.
Why "Security Through Obscurity" Isn't Enough
Some may think that security for subdomains can be maintained simply by keeping them hidden or “obscure,” under the assumption that “if it's not listed on Google, it's secure.” However, this approach—known as "security through obscurity"—is not effective for several reasons:
- Subdomains are Not Truly Hidden: CT logs make subdomains publicly visible, as certificates are issued for each specific subdomain. This means that even if a subdomain is not indexed by search engines, its existence may still be discoverable through CT logs or other public records. Tools and services exist specifically to monitor CT logs, making it trivial for attackers or curious individuals to find subdomains they otherwise might not have known about.
- Increased Risk of Attack on Unsecured Subdomains: By relying on obscurity, companies may inadvertently overlook the security of certain subdomains, especially test environments or internal systems. Attackers can identify and target these unprotected subdomains via CT logs, exploiting any weaknesses they find. Even non-public-facing test systems are susceptible to data breaches, unauthorized access, or being used as entry points into a company's larger network.
- Compliance and Best Practices Require Active Security: Properly securing applications and systems—especially those accessible over the internet—is a fundamental requirement for meeting compliance standards and security best practices. This applies to public and non-public environments alike. Trusting that unlisted subdomains will remain undiscovered often leads to vulnerabilities that put company and user data at risk.
How Certificate Transparency Enhances Security and Accountability
CT logs create a system of checks and balances by enabling the monitoring of all TLS certificates issued for a domain. This transparency can prevent attackers from obtaining rogue certificates that impersonate a company's website. Without CT, an attacker who compromised a Certificate Authority could create a valid-looking certificate for a target domain, intercepting or manipulating traffic in a classic “man-in-the-middle” attack. With CT logs, unauthorized certificates become easier to detect, and companies can act quickly to revoke them and mitigate any damage.
Risks of CT Logs for Sensitive Information
While CT logs are valuable for security, they can also reveal information that companies may wish to keep private. Each entry in a CT log contains details about the domain, including subdomains, associated with a certificate. For instance, if a certificate is issued for an internal system or test environment like test.internal.company.com
, this subdomain will be visible in the CT log. This exposure can inadvertently reveal details about internal infrastructure, development stages, or upcoming projects, potentially providing competitors or attackers with insights they otherwise wouldn’t have.
Securing All Systems, Including Test Environments
In an era where subdomains are easily discoverable, companies must prioritize securing all subdomains and environments—public-facing and internal alike. Test systems and internal tools, if accessible over the internet, should follow the same rigorous security protocols as production systems. This includes ensuring TLS encryption, enforcing access controls, and regularly reviewing access logs. Assuming that certain environments are “safe” because they're hidden is a dangerous mindset that often leads to critical security oversights.
In conclusion, CT logs serve as an essential tool for maintaining the integrity of online identities, protecting against fraudulent certificates, and ensuring transparency. However, they also highlight the importance of securing all systems comprehensively. Security through obscurity does not prevent attackers from finding subdomains; only active and thorough security practices will provide the necessary protection.